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PREFACE 


This  document  contains  the  notes  from  the  Defense  Modeling  and  Simulation  Office  (DMSO) 
Data  and  Repositories  Technology  Working  Group  (DRTWG)  meeting  and  related  Task  Force 
meetings  held  at  the  Institute  for  Defense  Analyses  (IDA)  during  February  7-10, 1995.  It  also 
contains  notes  for  DRTWG  Task  Force  and  Subgroup  meetings  held  between  the  previous 
Information/Database  Technical  Working  Group  (I/DBTWG)  meetings  during  the  week  of  July 
1 1-15,  1994  and  the  DRTWG  meetings  in  February.  (Note  that  the  DRTWG  was  formerly 
known  as  the  I/DBTWG). 

The  work  described  here  was  performed  for  the  DMSO  as  part  of  its  initiative  to  strengthen  the 
use  of  modeling  and  simulation  throughout  DoD.  RAND's  participation  in  this  effort  was 
performed  for  DMSO  within  the  Acquisition  and  Technology  Policy  Center  of  RAND's  National 
Defense  Research  Institute  (NDRI),  a  federally  funded  research  and  development  center 
sponsored  by  the  Office  of  the  Secretary  of  Defense,  Joint  Staff  and  the  defense  agencies. 

This  work  should  be  of  interest  to  those  working  in  the  areas  of  interoperability  of  information 
systems,  information  resource  management  (ERM),  data  dictionary  systems,  resource  directories, 
resource  repositories,  data  modeling  and  use  of  IDEF  tools,  complex  data,  data  verification, 
validation,  and  certification  (VV&C),  data  quality,  data/information  security,  and  assessment  of 
data  management  technology. 
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SUMMARY 


This  document  contains  the  notes  from  the  Defense  Modeling  and  Simulation  Office  (DMSO) 
Data  and  Repositories  Technology  Working  Group  (DRTWG)  meeting  and  related  Task  Force 
meetings  held  at  the  Institute  for  Defense  Analyses  (IDA)  during  February  7-10, 1995.  It  also 
contains  notes  for  DRTWG  Task  Force  and  Subgroup  meetings  held  between  the  previous 
Information/Database  Technical  Working  Group  (I/DBTWG)  meetings  during  the  week  of  July 
1 1-15,  1994  and  the  DRTWG  meetings  in  February.  (Note  that  the  DRTWG  was  formerly 
known  as  the  I/DBTWG). 

Because  data  is  critical  to  Modeling  and  Simulation,  the  main  and  continuing  purpose  of  the 
DRTWG  is  to  enable  data  providers  to  provide  the  M&S  community,  with  cost-effective,  timely, 
verified  and  valid  data  to  promote  reuse  and  sharing  of  data,  interoperability  of  models  and 
simulations,  and  improved  credibility  of  modeling  and  simulation  results. 

The  DoD  Corporate  Information  Management  (CIM)  initiative  continues  to  address  many  of  the 
data  related  needs  of  the  M&S  community  but  not  all.  It  is  important  for  the  M&S  community  to 
be  aware  of  the  data  needs  not  being  met  by  CIM  and  unlikely  to  be  met  by  commercial  or  other 
DoD  means.  These  data  needs  should  be  brought  to  the  attention  of  the  DoD  Data  Administrator 
and,  if  DoD  attention  to  them  is  not  timely  or  appropriate,  then  they  should  be  addressed  by  the 
M&S  community  through  the  Defense  M&S  Master  Plan  (draft  issued  in  January  1995)  and 
Investment  Plan  and  the  M&S  Data  Administration  Strategic  Plan  (DASP)  submitted  in  April 
1995.  It  is  critical  that  the  DRTWG  continue  to  monitor  DoD  CIM  activities  and  help  DMSO 
develop  compatible  M&S  guidelines  and  procedures  whenever  possible. 

The  DRTWG  is  currently  co-chaired  by  Dr.  Chien  Huo,  an  Associate  Director  of  DMSO,  and  by 
Ms.  Iris  Kameny,  an  Associate  Director  of  the  RAND  Acquisition  and  Technology  Policy 
Center,  who  has  been  supporting  DMSO  since  1991  in  their  data  related  activities.  Dr.  Huo  and 
Ms.  Kameny  are  working  with  CDR  Gary  Misch,  the  Technical  Director  of  DMSO,  and  with 
COL  Jerry  Wiedewitsch,  the  Deputy  Director  of  DMSO. 

The  DRTWG  has  grown  from  around  a  dozen  members  at  its  inception  to  over  200  members 
today.  It  consists  of  people  from  the  Services,  Joint  Staff,  DoD  agencies.  Intelligence 
Community,  ARPA,  NIST,  NASA,  OSD,  FFRDCs,  and  contractors  working  on  government 
M&S  programs.  The  DRTWG  currently  meets  twice  a  year.  The  DRTWG  has  four  Task 
Forces,  several  of  which  have  Subgroups.  The  co-chairs  of  the  Task  Forces  and  Subgroups  are 
predominantly  from  the  Services.  The  DRTWG  Task  Forces  and  Subgroups  meet  more 
frequently  as  needed. 

Because  of  its  size,  the  DRTWG  has  become  more  of  an  information  exchange  forum  for  the 
data  suppliers  to  the  M&S  community  than  an  action  body.  Members  make  requests  for 
information  and  the  meeting  agenda  is  developed  according  to  the  expressed  needs.  In  addition, 
DRTWG  members  and  others  are  invited  to  brief  about  their  M&S  projects,  database 
environments  and  centers  to  support  M&S,  and  non-M&S  oriented  databases  and  systems  used 
by  the  M&S  community.  This  exchange  has  been  very  helpful  in  getting  different  organizations 
to  know  each  other  and  work  together  toward  exchanging  and  reusing  databases  rather  than 
developing  redundant  databases. 

DRTWG  information  and  reports  can  be  accessed  through  the  M&S  Information  System  via 
Internet  gopher  at  gopher.dmso.mil  or  through  the  interim  M&S  Resource  Repository  (iMSRR) 
via  the  World  Wide  Web:  http://huachuca-jdbe.army.mil/  or  http://www.dmso.mil/ 
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Accomplishments  of  the  DRTWG  include: 

—  Support  of  DMSO  in  becoming  the  delegated  Functional  Data  Administrator  (FDAd)  for 
the  M&S  functional  area. 

—  Development  of  the  Modeling  and  Simulation  Data  Administration  Strategic  Plan 
(DASP)  for  FY  1995-2002. 

_  Development  of  the  initial  M&S  Information  System  (MSIS),  the  DRTWG  part  of  the 

MSIS,  and  the  first  interim  M&S  Resource  Repository  (iMSRR)  node. 

—  Development  of  initial  data  models  and  standards  for  M&S  Community  Directories  to 
include  a  Database  Directory,  a  Model  and  Simulation  Directory,  and  an  Authoritative 
Data  Sources  Directory  (each  can  be  used  as  a  "standard"  core  by  different  organizations 
enabling  sharing  of  directory  information  across  the  M&S  community). 

_  Development  of  a  methodology  to  build  subject  area  information  data  models  through 

reverse  engineering  of  legacy  databases  and  M&S  applications,  and  training 
organizations  in  carrying  out  these  activities  utilizing  IDEF  modeling  techniques. 

—  Definition  of  complex  data;  being  instrumental  in  getting  CIM  to  address  complex  data 
and  derived  data  in  their  new  Defense  Integrated  Repository  System  data  model;  and 
completion  of  an  initial  pilot  study  of  modeling  complexly  derived  data  using  the  Army 
TRAC  weapon  performance  data  (e.g.,  probability  hit,  kill)  and  sharing  the  lessons 
learned  with  the  community. 

—  A  paper  on  "Distributed  Interactive  Simulation  (DIS)  Needs  for  DoD  Data  Standards," 
which  was  instrumental  in  forming  the  DIS  Special  Interest  Group  (SIG)  for  Data 
Standards  and  Repositories  (DSR),  which  is  being  co-chaired  by  Dr.  Huo,  who  also  co¬ 
chairs  the  DRTWG. 

—  Development  of  data  verification,  validation,  and  certification  definitions  for  data 
producers  and  users 

To  expedite  work  in  data  related  support  for  M&S,  the  DRTWG  has  four  Task  Forces  in  the 

areas  of  Repositories,  Data  Standards,  Data  Security  Requirements  and  Data  VV&C. 

Specific  tasks  being  addressed  by  the  Repositories  Task  Force  include: 

_ Addressing  needs  and  requirements  (including  security,  protection  and  configuration 

management)  for  the  unclassified  iMSRR  based  on  the  Internet  WWW  and  for  the 
classified  iMSRR  which  may  be  based  on  Intelink-S;  implementing  the  iMSRR  node 
development  plan;  and  evaluating  its  use  to  provide  lessons  learned  for  development  of 
the  longer  range  distributed  MSRR  (based  on  a  common  architecture). 

_  Developing  the  concept  of  operations  and  requirements  (including  information  security, 

protection  and  configuration  management)  for  a  distributed  M&S  Resource  Repository 
system  (client/server  model)  that  can  meet  M&S  repository  needs  for  managing  metadata, 
instance  data,  algorithms,  models  and  simulations,  and  tools. 

Specific  tasks  to  be  addressed  by  the  Data  Standards  Task  Force  include:  * 

—  Working  with  the  M&S  FDAd  to  define  policy  and  procedures  for  carrying  out  M&S 
data  standardization  activities. 

—  Exploring  the  use  of  advanced  modeling  tools  for  modeling  complex  data  in  a  more  user 
friendly  way,  developing  metadata  extensions  to  describe  complex  data,  and  sharing  the 
findings  with  the  DISA/JIEO  Center  for  Software. 
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_ Performing  pilot  studies  on  complex  data,  in  particular  on  weapons  performance  data  for 

the  Navy  and  Air  Force  to  complement  the  previous  pilot  study  of  Army  weapons 
performance  data. 

Tasks  to  be  performed  by  the  Data  Security  Requirements  Task  Force  include: 

_  Identifying  official  policy  regarding  administration,  release,  use,  and  modification  ot 

data,  models,  and  simulations.  Identifying  policy  conflicts  and  producing  a  plan  for 
handling  them  so  that  users  can  access  and  use  the  data  and  M&S  they  need. 

—  Performing  a  data  security  requirements  survey  to  do  an  analysis  and  derive  the  best  set 
of  requirements.  Then  assessing  the  gap  between  the  requirements  and  the  capabilities  of 
current  DBMS  security  products  and  making  recommendations  of  M&S  data  systems  that 
could  be  implemented  in  the  ARPA  testbed  using  DBMS  security  products/methods  to 
verify  the  requirements  and  behavior  of  the  systems. 

_  Aiding  the  iMSRR  and  MSRR  development  and  requirement  teams  in  understanding  the 

security  and  protection  requirements  and  techniques  available  and  helping  them  make 
security-related  architectural  decisions. 

Specific  tasks  being  addressed  by  the  Data  VV &C  T ask  Force  include: 

_  Carrying  out  VV&C  tasks  to  determine  data  VV&C  procedures  and  guidelines  for  M&S 

non-DIS  users,  DIS  users,  and  data  producers. 

_  Developing  a  data  quality  profile  to  describe  the  condition  of  a  dataset  or  database  (e.g., 

completeness,  accuracy,  resolution,  audit  trail,  derivation,  and  the  V&V  tests  applied  to 
the  data)  and  requiring  that  the  profile  be  part  of  the  data  certification  process  as  well  as  a 
part  of  the  M&S  Verification,  Validation,  and  Accreditation  process. 

—  Addressing  Authoritative  Data  Sources:  Developing  taxonomy  of  data  areas,  identifying 
authorities  for  those  areas,  developing  a  directory  of  the  authorities,  and  a  guideline  to 
responsibilities  of  an  Authoritative  Data  Source.  Defining  the  roles  of  M&S  data  centers 
that  receive  data  from  authoritative  sources  and  prepare  it  for  input  to  models. 

—  Working  with  the  DIS  Verification,  Validation  and  Accreditation  (VV&A)  WG  and  the 
DMSO  VV&A  TWG  to  integrate  the  data  VV&C  process  into  DIS  and  non-DIS  VV&A 
processes. 
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1.0  INTRODUCTION 


PURPOSE 

The  purpose  of  this  document  is  to  provide  to  DRTWG  members  notes  of  the  February  7-10 
Defense  Modeling  and  Simulation  Office  (DMSO)  Data  and  Repositories  Technology  Working 
Group  (DRTWG)  meetings,  and  notes  from  other  DRTWG  Task  Force  and  Subgroup  meetings 
held  since  the  previous  I/DBTWG  meeting  in  July  1994.  In  addition,  it  provides  mfoimation  to 
people  who  wish  to  participate  in  the  DRTWG  and  those  with  an  interest  in  data  activities  related 
to  modeling  and  simulation. 


BACKGROUND 

In  1991  the  Deputy  Secretary  of  Defense  instituted  a  major  new  initiative  to  strengthen  the 
application  of  modeling  and  simulation  (M&S)  in  the  DoD.  Its  purpose  is  to  promote  the 
effective  and  efficient  use  of  M&S  in  joint  education,  training  and  military  operations,  research 
and  development,  test  and  evaluation,  analysis,  and  production  and  logistics  by:  (1)  establishing 
Office  of  the  Secretary  of  Defense  (OSD)  cognizance  and  facilitating  coordination  among  DoD 
M&S  activities;  (2)  promoting  the  use  of  interoperability  standards  and  protocols  where 
appropriate;  and  (3)  stimulating  joint  use,  high  return  on  M&S  investment.  Achievement  of 
these  goals  requires  the  development  and  implementation  of  a  DoD  M&S  policy,  establishment 
of  a  DoD-wide  management  structure  to  coordinate  joint  M&S  activities  and  requirements,  and 
the  formulation  and  implementation  of  a  long  range  M&S  joint  investment  strategy. 

The  then-USD(A)  established  the  Defense  Modeling  and  Simulation  Office  (DMSO)  on  June  21, 
1991  to  serve  as  the  executive  secretariat  for  the  Executive  Council  on  Modeling  and  Simulation 
(EXCIMS)  and  to  provide  a  full-time  focal  point  for  information  concerning  DoD  modeling  and 
simulation  (M&S)  activities.  Currently,  the  DMSO  promulgates  USD(A&T)  directed  M&S 
policy,  initiatives,  and  guidance  to  promote  cooperation  among  DoD  components  to  maximize 
efficiency  and  effectiveness. 

To  carry  out  its  functions  and  develop  a  master  plan,  the  DMSO  enlisted  the  help  of  several 
Federally  Funded  Research  and  Development  Centers  (FFRDCs).  A  number  of  functional  and 
technology  working  groups  were  established  to  determine  the  M&S  needs  and  to  evaluate  the 
state-of-the-art  with  respect  to  those  needs.  The  Functional  Working  Groups  are:  Education, 
Training  and  Military  Operations  (ETMO);  Research  and  Development;  Test  and  Evaluation; 
Analysis;  and  Production  and  Logistics.  The  current  Technology  Working  Groups  are. 
Architecture;  Data  and  Repositories;  Environmental  Representations;  Systems/Verification, 
Validation  and  Accreditation;  and  Human  Behavior  Representations. 


The  current  DRTWG  grew  out  of  two  original  TWGs:  The  Information  TWG  and  the  Database 
TWG.  During  initial  startup  activities  in  January  1992,  the  Information  Technology  Working 
Group  (ITWG)  began  to  develop  plans  and  design  of  a  DMSO  Information  System  to  meditate 
coordination  among  DoD  M&S  activities.  The  Database  Technology  Working  Group  (  ) 

identified  three  efforts  found  critical  to  M&S  needs:  (1)  need  for  directories,  dictionaries, 
encyclopedias,  and  repositories  to  support  timely  and  cost  effective  access  to,  acquisition  ot,  ana 
validation  of  external  and  derived  databases;  (2)  interoperability,  data  integrity  an  consis  ency 
across  distributed  databases  and  simulations;  and  (3)  M&S  community  objective  assessment  ot 
data  management  products  such  as  relational  DBMSs.  COL  Jim  Shiflett,  former  Technical 
Director  of  DMSO,  asked  that  the  two  TWGs  be  joined  into  the  I/DB  Task  Group  which  was 
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done.  Recently,  upon  DMSO  resurrection  of  the  TWGs,  the  name  of  the  I/DB  Task  Group  was 
changed  to  the  DRTWG. 


Three  documents  describing  earlier  I/DBTWG  activities  are:  (1)  Defense  Modeling  and 
Simulation  Office  Information/Database  Technology  Working  Group  (I/DBTWG)  Meetings 
Held  During  the  Week  of  July  11-15, 1994,  CF-1 15-OSD;  (2)  Defense  Modeling  and  Simulation 
Office  Information/Database  (I/DB)  Task  Group  Meetings  Held  February  14-18,  1994,  and 
Notes  from  the  Previous  Two  I/DB  Meetings,  RAND  CF-1 14-DMSO,  1994;  and  (3)  Database 
Technology  Activities  and  Assessment  for  Defense  Modeling  and  Simulation  Office  (DMSO) 
(August  1991  -  November  1992),  RAND  MR-130-ACQ,  1994. 


The  DRTWG  is  currently  co-chaired  by  Dr.  Chien  Huo,  an  Associate  Director  of  DMSO,  and  by 
Ms  Iris  Kameny,  an  Associate  Director  for  the  RAND  Acquisition  and  Technology  Policy 
Center  who  has  been  supporting  DMSO  since  1991  in  their  data  related  activities.  Dr.  Huo  and 
Ms.  Kameny  are  working  with  CDR  Gary  Misch,  the  Technical  Director  of  DMSO,  and  with 
COL  Jerry  Wiedewitsch,  the  Deputy  Director  of  DMSO. 


The  DRTWG  has  grown  from  around  a  dozen  members  at  its  inception  to  over  200  members 
today  It  consists  of  people  from  the  Services,  Joint  Staff,  DoD  agencies,  Intelligence 
Coninunity,  ARPA,  NIST,  NASA,  OSD,  FFRDCs,  and  contractors  working  on  government 
M&S  programs.  The  DRTWG  currently  meets  twice  a  year  with  the  next  meeting  scheduled  tor 
August  1-4, 1995  at  the  Institute  for  Defense  Analyses  in  Alexandria,  Virginia.  The  DRTWG 
has  four  Task  Forces  (Repositories;  Data  Standards;  Data  Security;  and  Data  Verification, 
Validation  &  Certification  (VV&C)).  Several  of  these  task  forces  have  Subgroups.  Theco- 
chairs  of  the  Task  Forces  and  Subgroups  are  predominantly  from  the  Services.  The  DRTWG 
Task  Forces  and  Subgroups  meet  more  frequently  as  needed. 


Because  of  its  size,  the  DRTWG  has  become  more  of  an  information  exchange  forum  for  the 
data  suppliers  to  the  M&S  community  than  an  action  body.  Members  make  requests  for 
information  mainly  about  data  standards,  repositories,  directories,  data  quality,  comply  data,  etc. 
and  the  meeting  agenda  is  developed  according  to  the  expressed  needs.  In  addition,  DRTWG 
members  and  others  are  invited  to  brief  about  their  M&S  projects,  database  environments  and 
centers  to  support  M&S,  and  non-M&S  oriented  databases  and  systems  used  by  the  M&S 
community.  This  exchange  has  been  veiy  helpful  in  getting  different  organizations  to  know  each 
other  and  work  together  toward  exchanging  and  reusing  databases  rather  than  developing 
redundant  databases. 


DRTWG  information  and  reports  can  be  accessed  through  the  M&S  Information  System  via 
Internet  gopher  at  gopher.dmso.mil  or  through  the  interim  M&S  Resource  Repository  (iMSRR) 
via  the  World  Wide  Web:  http://huachuca-jdbe.army.mil/  or  http://www.dmso.mil/ 


OBJECTIVES  OF  THE  DRTWG 

Because  data  is  critical  to  models  and  simulations,  the  main  and  continuing  objective  of  the 
DRTWG  is  to  support  the  M&S  data  administration  program  to: 

enable  data  suppliers  to  provide  the  M&S  community  cost  effective, 
timely,  and  verified  and  validated  data  to  promote  reuse  and  sharing  of  data, 
interoperability  of  models  and  simulations,  and  improved  credibility 
of  modeling  and  simulation  results. 

To  accomplish  this  goal  requires  data  administration  policies,  procedures,  standards,  and 
supporting  tools  compatible  with  those  of  CIM  and  the  Services.  It  also  requires  access  to 
information  throughout  the  M&S  community  about  what  is  happening  as  well  as  information 
about  the  existence  and  availability  of  models  and  simulations  and  the  data  they  need.  Of  critical 
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concem  to  the  community,  is  the  quality  of  the  models  and  simulations  as  well  as  the  data  they 
use  and  generate.  Current  responsibility  for  meeting  data  administration  objectives  is  being 
addressed  through  the  delegation  of  M&S  functional  area  data  administration  responsibility  to 
DMSO.  Under  the  direction  of  the  USD(A&T)  and  the  Director,  Defense  Research  and 
Engineering  (DDR&E),  DMSO  is  delegated  with  the  full  mission  and  authority  as  the  Functional 
Data  Administrator  (FDAd)  for  M&S.  Dr.  Chien  Huo  is  the  point  of  contact  for  the  M&S  FDAd 
and  delivered  the  first  Data  Administration  Strategic  Plan  (DASP)  to  the  DoD  Data 
Administrator  in  April  1995. 

The  DRTWG  has  worked  with  the  M&S  FDAd  to  address  data-related  areas  in  the  Draft  Defense 
M&S  Master  Plan  (MSMP)  (January  1995),  and  to  develop  an  investment  program  to  carry  out 
tasks  to  meet  the  MSMP  activities  and  milestones.  The  MSMP  identifies  six  DoD  M&S 
Objectives,  most  of  which  have  several  Sub-objectives.  Major  DRTWG  related  activities  fall 
under  three  of  these  Sub-objectives:  Sub-objective  1-3  will  establish  data  standards  to  support 
common  representations  of  data  in  models  and  simulations;  Sub-objective  5-2  will  develop 
methodologies,  standards,  and  procedures  for  the  VV&A  of  models  and  simulations  and  the 
VV&C  of  data  used  in  M&S;  and  Sub-objective  5-3  will  provide  a  distributed  repository  system 
to  facilitate  developer  and  end-user  access  to  M&S  resources.  In  addition,  the  DRTWG  efforts 
will  support  other  MSMP  Objectives  with  relevant  data  standards  and  use  of  the  distributed 
M&S  Resource  Repositories  (MSRR)  for  providing  authoritative  representations  of  the  natural 
environment,  systems,  and  human  behavior. 

PLANNED  ACTIVITIES 

I.  Sub-objective  1-3.  The  following  activities  support  Sub-objective  1-3  (establish  data 
standards  to  support  common  representations  of  data  in  models  and  simulations): 

Support  for  Data  Standards.  In  support  of  data  standards:  The  M&S  FDAd  will  arrange 
for  registering  M&S  users  on  the  DDRS;  develop  M&S  Data  Administration  (DA) 
procedures  for  carrying  out  data  standardization;  maintain  information  on  M&S  standard 
data  resources  in  the  DDRS  and  on  the  iMSRR;  use  the  DoD  Personal  Computer  Access 
Tool  (PCAT)  for  accessing  standard  data  element  definitions  and  for  submitting  data 
standards  for  standardization;  and  continue  developing  the  reverse  engineering 
methodology  to  support  the  development  of  data  models  and  standards  from  legacy 
databases  and  M&S.  The  Joint  Database  Elements  (JDBE)  project  personnel  will  also  be 
available  to  M&S  data  projects  for  IDEF  training  and  help  in  developing  their  data 
models. 

Support  for  Complex  Data.  The  DRTWG  recognized  the  lack  of  attention  in  the  CIM 
community  to  data  standards  for  scientific  and  technical  data  and  formed  the  Complex 
Data  Subgroup  of  the  Data  Standards  Task  Force  to  address  these  needs.  Much  M&S 
data  is  not  atomic  single  concept  data  addressed  by  the  CIM  data  standardization  process 
(in  accordance  with  DoD  8320.1-M-l)  but  is  complexly  derived  (e.g.,  probability  hit,  kill) 
structurally  complex  (e.g.,  a  road  network,  an  object-oriented  engineering  view  of  a 
weapon  system)  multimedia  (e.g.,  images,  graphics,  voice)  or  conceptually  complex  (e.g., 
rules,  operation  orders)  data.  Complex  data  tasks  will  include  finding  and  trying  out  new 
data  modeling  techniques  that  will  be  more  user  friendly  and  to  perform  additional  pilot 
studies  using  these  modeling  techniques  (preferably  for  Air  Force  and  Navy  weapons 
performance  data). 

DIS  Data  Standards:  The  DIS  Data  Standards  Subgroup  presented  a  paper  at  the  1 1th 
DIS  Workshop  (September  1994)  on  "DIS  Needs  for  DoD  Data  Standards"  and  was 
instrumental  in  the  formation  of  the  new  DIS  SIG  on  Data  Standards  and  Repositories 
(DSR)  which  held  its  first  meeting  at  the  12th  DIS  Workshop  in  March  1995.  DMSO  is 
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supporting  work  for  developing  a  DIS  Data  Element  Dictionary  based  on  objects  referred 
to  in  DIS  PDUs. 

Data  Security  Requirements.  This  task  force  will  be  identifying  and  resolving  data 
security  issues,  developing  policy  and  requirements,  and  recommending  policy  for  data 
protection,  access  and  sharing. 

Sub-objective  5-2:  The  following  activities  support  Sub-objective  5-2  (develop 
methodologies,  standards,  and  procedures  for  the  VV&A  of  models  and  simulations  and 
the  VV&C  of  data): 

Data  VV&C.  The  VV&C  Task  Force  has  two  Subgroups:  The  VV&C  Guidelines  and 
Quality  Profile  Subgroup  and  the  Authoritative  Data  Sources  Subgroup. 

The  Guidelines  Subgroup  is  carrying  out  several  tasks  to  develop  guidelines  for  die 
VV&C  of  data  and  is  working  closely  with  the  DMSO  VV&A  TWG  and  the  DIS 
Fidelity,  Management  and  Usability  Working  Group  VV&A  Subgroup  to  integrate  the 
data  VV&C  process  into  the  DIS  and  non-DIS  VV&A  processes.  Guidelines  for  data 
VV&C  include  the  definition  of  a  data  quality  profile  to  describe  the  condition  of  a 
dataset  or  database  (e.g.,  completeness,  accuracy,  resolution,  audit  trail,  derivation,  and 
the  V&V  tests  applied  to  the  data)  and  requiring  that  the  profile  be  part  of  the  data 
certification  process. 

The  Authoritative  Data  Sources  Subgroup  is  concerned  with  the  ability  of  M&S  users  to 
find  and  acquire  the  instance  data  they  need  for  their  M&S  and  for  that  data  to  be 
W&Ced,  configuration  managed,  etc.  This  Subgroup  is  developing  a  taxonomy  of  data 
areas,  identifying  authorities  for  those  areas,  developing  a  directory  of  the  authorities,  and 
a  guideline  to  responsibilities  of  an  Authoritative  Data  Source.  They  are  also  defining  the 
roles  of  M&S  data  centers  that  receive  data  from  authoritative  sources  and  prepare  it  tor 
input  to  models  and  are  concerned  with  release  authority  issues. 

Sub-objective  5-3  The  following  activities  support  Sub-objective  5-3  (provide  a 
distributed  repository  system  to  facilitate  developer  and  end-user  access  to  M&S 
resources): 

Development  of  MSRR.  DMSO  is  supporting  a  project  to  develop  a  distributed  system 
of  M&S  Resource  Repositories  (MSRR)  providing:  M&S  Community  Directories,  data 
standardization  resources  (e.g.,  process  and  data  models,  data  dictionary)  algorithms, 
models  and  simulations,  and  the  tools  for  browsing  and  accessing,  linking  across 
resources,  configuration  management,  etc. 

Development  of  M&S  Community  Directories.  This  is  an  ongoing  effort  to  provide  a 
Database  Directory,  a  Model  and  Simulation  Directory,  and  an  Authoritative  Data 
Sources  Directory  on  the  iMSRR.  Each  directory  schema  can  be  used  as  a  standard 
core  by  different  organizations  enabling  sharing  of  directory  information  across  the  M&S 

community. 

M&S  Information  System  (MSIS).  The  M&S  Information  System  was 

meet  the  M&S  community's  needs  for  access  to  information.  DRTWG  information 

documents  and  activities  are  maintained  on  the  MSIS  as  well  as  on  the  interim  MSRR 

(iMSRR). 
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ORGANIZATION  AND  STRUCTURE  OF  TfflS  DOCUMENT 

This  document  contains  the  notes  from  the  DMSO  DRTWG  meeting  and  related  Task  Force  and 
Subgroup  meetings  held  at  the  Institute  for  Defense  Analyses  (IDA).durmg  February  7-10,  1995. 
In  addition,  it  contains  notes  for  DRTWG  Task  Force  and  Subgroup  meetings  held  between  the 
previous  Information/Database  Technical  Working  Group  (I/DBTWG)  meetings  in  July  1994 
and  the  DRTWG  meetings  in  February. 

Section  1  contains  the  introduction. 

Section  2  contains  the  highlights  of  the  DRTWG  meetings  held  during  February  7-10, 
1995. 

Section  3  contains  notes  for  the  main  DRTWG  meeting  held  February  7-8,  1995  which 
includes  an  update  on  DMSO  happenings;  reports  from  DRTWG  task  forces  and 
subgroups;  updates  on  data  administration,  standardization  and  modeling  activities; 
reports  about  other  organizations;  reports  from  Service  M&S  organizations  with  respect 
to  data  related  activities;  reports  from  the  Environmental  Representation  TWG;  and 
reports  from  M&S  data  related  projects. 

Section  4  contains  notes  from  the  Data  W&C  Guidelines  Subgroup  Meeting  held  on 
February  8,  1995. 

Section  5  contains  notes  from  the  Joint  VV&A  TWG  and  Data  VV&C  Task  Force 
Meeting  held  on  February  9, 1995. 

Section  6  contains  notes  from  the  Authoritative  Data  Sources  Subgroup  Meeting  held  on 
February  9, 1995. 

Section  7  contains  notes  from  the  Data  Security  Requirements  Task  Force  Meeting  held 
on  February  10, 1995. 

Section  8  contains  notes  from  the  Repositories  Task  Force  Meeting  held  on  August  15- 

16. 1994. 

Section  9  contains  notes  from  the  Authoritative  Data  Sources  Subgroup  Meeting  held  on 
September  9, 1994. 

Section  10  contains  notes  from  the  Repositories  Task  Force  Meeting  held  on  October  17, 
1994. 

Section  1 1  contains  notes  from  the  Data  W&C  Task  Force  Meeting  held  on  October  18- 

19. 1994. 

Section  12  contains  notes  from  the  Authoritative  Data  Sources  Subgroup  Meeting  held  on 
November  3, 1994. 

Section  13  contains  notes  from  the  Data  Security  Requirements  Task  Force  Meeting  held 
on  December  14, 1994. 

Section  14  contains  notes  from  the  Authoritative  Data  Sources  Subgroup  Meeting  held  on 
December  15,  1994. 
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2.0  DRTWG  MEETING  HIGHLIGHTS 


The  DRTWG  Conference  was  a  success.  Dr.  Chien  Huo  of  DMSO,  Ms.  Iris  Kameny  of  RAND, 
and  Services'  representatives  co-chaired  the  DRTWG  plenary  session  and  its  related  meetings: 
Data  VV&C  Subgroup,  Authoritative  Data  Sources  Subgroup,  Date  Security  Requirements  Task 
Force,  and  the  first  joint  meeting  of  the  M&S  VV&A  TWG  with  the  DRTWG  Data  VV&C  Task 
Force.  Over  60  people  attended,  representing  the  Services,  Joint  Staff,  OSD,  DMA,  DIA, 
JIEO/CIM,  CINCs,  industry  and  academia.  The  conference's  main  focus  was  on  DMSO 
activities,  including  the  M&S  Master  Plan,  the  M&S  Data  Administration  Strategic  Plan  (DASP) 
DRTWG  Task  Force  and  Subgroup  activities,  and  reports  from  the  Environmental  TWG  and 
DMSO  funded  projects  (MSIM,  UTSS,  VV&A  of  Distributed  Simulations,  and  the  CENTCOM 
Data  Quality  Engineering  tool).  A  highlight  was  COL  Jerry  Wiedewitsch’s  discussion  of  the  new 
DMSO  organization,  and  the  M&S  Master  Plan  (with  attention  to  its  data  related  activities).  He 
also  discussed  DMSO's  participation  in  a  number  of  DoD  activities  that  require  attention  from 
the  DRTWG,  including:  The  Leading  Edge  Environment  for  Global  Command  and  Control 
(LEEGCCS),  the  Advanced  Joint  Planning  Advanced  Concept  Technology  Demonstration  (AJP 
ACTD),  the  Joint  Warrior  Interoperability  Demonstrations  (JWID);  and  the  Synthetic  Theater  of 
War  (STOW)  for  97.  He  also  discussed  the  development  of  a  new  generation  of  simulations, 
Joint  Simulation  (JSIMS),  based  on  a  High  Level  Architecture  (HLA)  that  was  developed  by 
ARPA.  Dr.  Chien  Huo  discussed,  in  greater  detail,  the  data  related  parts  of  the  Master  Plan,  the 
investment  plan,  and  how  the  MSMP  data-related  goals  will  be  achieved. 

Upcoming  Activities: 

—  A  new  DIS  SIG  on  Data  Standards  and  Repositories  has  been  formed  and  will  meet  for 
the  first  time  at  the  12th  DIS  Workshop  in  March. 

—  The  next  DRTWG  meetings  will  be  held  August  1-4  at  IDA  in  Alexandria. 


Highlights  From  the  Task  Force  Subgroup  Meetings: 

a.  Data  VV&C  Subgroup  Meeting 

—  The  focus  was  on  the  tasks  to  develop  W&C  Guidelines:  Task  1  for  non-DIS  users 
of  M&S,  and  Task  3  for  data  producers  of  data  for  M&S.  (Task  2,  for  DIS  users,  will 
use  the  results  from  the  DIS  VV&A  Working  Group.) 

—  Plans  were  made  for  conducting  a  kickoff  meeting  in  Albuquerque,  February  27-28, 
for  Task  1  and  Task  3  leaders,  supporting  organizations,  case  study  representatives 
and  JDBE IDEFO  facilitators. 

—  A  deliverable  was  added  to  the  W&C  Task  Description  for  a  draft  final  report  by  31 
December  1995. 

b.  Authoritative  Data  Sources  Meeting: 

—  The  objectives  of  this  meeting  were  to  (1)  determine  the  status  of  the  JM&S  Data  Sources 
Survey;  (2)  discuss  data  source  responsibility  issues;  and  (3)  to  finalize  the  JM&S 
taxonomy  for  the  data  sources  directory.  Objective  (1)  was  met.  Objective  (2)  resulted  in 
an  action  item  due  in  by  26  April.  Intermediate  deadlines  are  12  April  and  19  April. 
Objective  (3)  resulted  in  the  taxonomy  being  baselined  pending  final  input  from  working 
group  members,  comments  from  the  DRTWG,  and  action  items  due  in  by  28  February. 
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c.  Data  Security  Requirements  Task  Force  Meeting: 

_  Objectives  of  the  meeting  were  to  follow  up  on  the  action  items  assigned  at  the 

previous  meeting:  briefs  on  security  products  (NCSC),  releasability,  TAFIM  Volume 
6,  Component  security  policy.  Navy  Integration  Data  Management  System  lessons 
learned,  standard  way  of  labeling,  and  ways  to  filter  and  declassify  data. 

_ Two  security  tasks  were  to  get  underway  to  address:  categorization  of  individual 

M&S  data  systems  data  security  requirements  and  suggest  technology  solutions 
(MITRE),  and  definition  of  policy  issues  and  suggested  changes  (RAND)  -  but  the 
FFRDCs  were  not  able  to  perform  these  near-term  efforts  and  the  co-chairs  were 
looking  into  having  the  tasks  performed  by  the  Naval  Research  Laboratory  (NRL). 

_ The  next  meeting  will  be  held  after  the  two  security  tasks  have  started.  The  agenda 

will  include  briefs  on  physical  security,  data  aggregation  policy,  and  Intelink. 

d.  Joint  VV&A  TWG  and  Data  VV&C  Task  Force  Meeting: 

_ The  objective  of  the  meeting  was  to  familiarize  each  group  with  the  objectives  and 

accomplishments  of  the  other  group  so  there  can  be  better  coordination  and 
cooperation  in  the  future. 

_  Dr.  Huo  will  work  with  Dr.  Sanders  to  identify  representatives  from  the  two  groups 

that  will  coordinate  the  pilot  studies  being  undertaken. 

_ The  joint  meeting  was  successful  and  plans  were  discussed  for  having  another  joint 

meeting  during  the  August  DRTWG  meetings. 
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3.0  NOTES  FROM  NINTH  DRTWG  MEETING  AT  IDA 
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3.1  AGENDA 


TUESDAY  FEBRUARY  7, 1995 
UPDATE  ON  DMSO  HAPPENINGS 


0800  -  0830 
0830  -  0900 
0900  -  0930 
0930  -  1000 
1000  - 1030 
1030-  1100 

1100-1120 

1120-1140 
1140-1200 
1200  -  1220 
1220-  1320 
1320  -  1340 
1340  -  1410 
1410  - 1430 

1430  -  1500 
1500  -  1530 
1530  -  1600 
1600  -  1630 
1630  -  1700 


Welcome  -  Introduction:  COL  Jerry  Wiedewitsch 
M&S  Master  Plan  Update:  Dr.  Chien  Huo 
Status  of  Data  Standardization:  Ms.  Linda  Calvert 
Environment  TWG  Data  Needs:  Mr.  Paul  Foley 
Break 

Data  Needs  for  Synthetic  Theater  of  War  (STOW):  Dr.  Randy  Garrett 
REPORT  FROM  INTELLIGENCE  FDAD 
Report  from  Intelligence  FDAd:  Mr.  Jim  Davidson 
REPORTS  FROM  DRTWG  TASK  FORCES  AND  SUBGROUPS 
VV&C  Guidelines  Subgroup:  Mr.  Mark  Ralston  and  Mr.  Bob  Hartling 
Authoritative  Data  Sources  Subgroup:  Mr.  Mike  Hopkins 
Data  Security  Requirements  Task  Force:  Ms.  Teresa  Lunt  and  Dr.  Chien  Huo 

Lunch 

Repository  Subgroup:  Mr.  Jim  Augins  and  Mr.  Peter  Valentine 
WWW  Implementation  Plans:  Mr.  Jim  Augins  and  Mr.  Pete  Valentine 
Data  Standards  Task  Force:  MAJ  Walt  Swindell  and  Ms.  Linda  Calvert 
DMSO  FUNDED  PROJECTS 

Modeling  and  Simulation  Information  Management:  Mr.  Robert  Hulsman 
Break 

Data  Quality  Engineering  Tool  Project:  Mr.  Mike  Hopkins 
Universal  Threat  System  for  Simulators:  Mr.  Jim  Santangelo 
VV&A  of  Distributed  Simulation  Project:  Ms  Susan  Solick 


- 12- 


WEDNESDAY  FEBRUARY  8,  1995 
REPORTS  FROM  OTHER  GROUPS 
0800  -  0820  IEEE  IDEF1X  Working  Group:  Mr.  Peter  Valentine 
0820  -  0840  Report  on  Navy  Data  Administration  Program:  Ms.  Rebecca  Wade 

REPORT  ON  THE  DMSO  DIRECTORIES 
0840  -  0910  M&S  Directories:  Dr.  Mike  Frame  and  Ms.  Peggy  Gravitz 

REPORTS  FROM  DISA/JIEO 
0910-0940  DoD  Repository:  Mr.  Peter  Pasek 
0940  - 1010  Data  Quality  and  Security:  Ms.  Miranda  Stem 
1010  - 1030  Break 

1030  - 1 100  Global  Command  and  Control  System  (GCCS)  Data  Needs:  Ms.  Angela  Booker 
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3.3  UPDATE  ON  DMSO  HAPPENINGS 

COL  Jerry  Wiedewitsch,  Deputy  Director  of  DMSO:  DoD  Modeling  and  Simulation: 
Putting  the  Warfighter  in  the  Loop 

COL  Wiedewitsch  began  by  welcoming  everyone  to  the  9th  DRTWG  meeting.  He  stressed  that 
DMSO  would  like  to  bring  modeling  and  simulation  into  the  C4I  world  as  a  service.  The  vision 
is  that  "defense  modeling  and  simulation  will  provide  readily  available,  operationally  valid 
environments  for  use  by  DoD  components  to  train  jointly,  develop  doctrine  and  tactics,  formulate 
operational  plans,  and  assess  war  fighting  situations  as  well  as  to  support  technology  assessment, 
system  upgrade,  prototype  and  full  scale  development  and  force  structuring.  Furthermore, 
common  use  of  these  environments  will  promote  a  closer  interaction  between  the  operations  and 
acquisition  communities  in  carrying  out  their  respective  responsibilities.  To  allow  maximum 
utility  and  flexibility,  these  modeling  and  simulation  environments  will  be  constructed  from 
affordable,  reusable  components  interoperating  through  an  open  systems  architecture." 

He  went  over  the  new  DMSO  organization:  CAPT  Jim  Hollenbach  is  the  DMSO  Director,  COL 
Jerry  Wiedewitsch  is  the  Deputy  Director,  Mr.  Gary  Yerace  is  the  Chief  of  Staff  and  in  charge  of 
office  administration  and  management.  There  are  four  divisions:  The  Science  and  Technology 
Division  is  lacking  a  chief  scientist  but  CDR  Gary  Misch  is  the  acting  head,  the  Technology 
Application  Division  is  headed  by  CDR  Gary  Misch,  the  Operations  Division  is  headed  by  LtCol 
Dave  Bartlett,  and  the  Business/Financial  Management  Division  is  headed  by  Mr.  Waverly 
Debraux.  The  chart  indicated  where  the  various  DRTWG  activities  fall  (mainly  in  the  Science 
and  Technology  and  Technology  Application  Divisions). 

He  discussed  the  DoD  M&S  management  structure  showing  Under  Secretary  of  Defense 
(Acquisition  &  Technology)  (USD(A&T)  at  the  top.  Director  Defense  Research  &  Engineering 
(DDR&E)  and  the  Executive  Council  for  Modeling  and  Simulations  (EXCIMS)  in  the  middle, 
and  DMSO  and  the  Modeling  and  Simulation  Working  Group  (MSWG)  at  the  bottom  level, 
including  DoD  Component  representatives.  Off  the  lower  level  comes  the  Functional  Work 
Groups,  the  Technology  Work  Groups  and  the  Task  Forces.  The  Technology  Work  Groups  have 
been  changed  to  reflect  the  Defense  Master  Plan.  They  are:  Architecture,  Data  and  Repositories, 
Environmental,  Systems/VVA,  and  Human  Behavior.  The  name  of  the  I/DBTWG  has  been 
changed  to  the  DRTWG  to  better  describe  its  role  with  respect  to  the  Defense  M&S  Master  Plan 
and  the  other  TWGs.  Activities  will  continue  much  as  before  but  with  Master  Plan  focus  and 
more  interaction  with  the  other  TWGs.  He  then  showed  an  integrated  M&S  Data  Administration 
infrastructure  which  detailed  where  the  M&S  FDAd  is  with  respect  to  DDR&E,  the  M&S 
Integrated  Process  Teams,  the  DRTWG  and  its  Task  Forces  and  Subgroups,  and  the  Component 
M&S  offices. 

Many  things  are  happening:  The  DoD  M&S  Master  Plan  is  in  coordination;  an  Architecture 
Management  Group  (to  operate  in  an  open  forum  much  like  the  Internet)  has  been  established;  an 
ARPA/DISA  Advanced  Information  Technology  Services  JPO  has  been  established  (to  manage 
DSI  and  C4I  initiatives,  including  Leading  Edge  Environment  for  Global  Command  and  Control 
(LEEGCCS),  Advanced  Joint  Planning  (AJP),  Advanced  Concept  Technology  Demonstration 
(ACTD),  and  the  Joint  Warrior  Interoperability  Demonstration  (JWID).  DMSO  is  participating 
in  Synthetic  Theater  of  War  (STOW)  97  activities  and  in  the  development  of  a  new  generation  of 
simulations.  Joint  Simulations  (JSIMS).  COL  Wiedewitsch  went  through  the  six  objectives  of 
the  DoD  M&S  Master  Plan  showing  data  as  part  of  five  of  the  objectives.  Data  is  getting 
attention,  funding,  and  is  very  important  to  the  success  of  the  master  plan. 

DoD  modeling  and  simulation  is  looked  at  as  the  base  for  supporting  the  four  pillars  of  military 
capability:  force  structure,  modernization,  readiness,  and  sustainability.  The  strategy  presented 
to  the  DSB  is  to  jointly  establish  a  communication  framework  (through  an  open  forum  much  like 
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the  Internet),  a  high  level  architecture,  data  standards  and  a  repository  of  reusable  elements.  An 
operational  concept  shows  the  C4I  System  Logical  Networks  interacting  with  the  M&S  Logical 
Networks,  for  example  to  enable  a  simulation  to  use  a  plan  from  an  operational  system  and 
feedback  results  to  the  operational  users.  This  would  enable  the  use  of  M&S  in  developing 
operational  plans,  training,  mission  rehearsals,  and  battle  and  would  make  real  world  data  (e.g., 
intelligence,  weather,  imagery)  available  to  M&S.  DMSO  needs  to  define  environmental, 
systems  and  behavioral  authoritative  representations  and  establish  executive  agents  for  these 
(DMA  was  recently  established  as  the  executive  agent  for  terrain).  A  corporate  DoD  process  for 
VV&A  is  being  developed.  There  are  plans  to  use  fielded  C2I  systems  in  M&S  exercises  and 
thus  a  need  for  the  Components  to  work  closer  with  the  DIS  steering  committee. 

COL  Wiedewitsch  went  over  the  USACOM  STOW  97  and  beyond  requirements  to  develop  a 
joint,  entity  level,  object-based  simulation  system  for  Joint  Task  Force  (JTF)  crisis  rehearsals  and 
exercises  using  higher  quality  simulation,  lower  overhead,  and  object  code  reuse.  The  most 
interesting  requirement  with  respect  to  the  DRTWG  is  the  requirement  to  do  fast  database  builds 
-  96  hours  in  a  crisis.  (An  action  item:  Iris  Kameny  will  be  gathering  a  small  group  to  begin  to 
address  this  requirement).  STOW  97  will  require  technologies  for:  synthetic  forces,  synthetic 
environments,  information  and  networking  technology  and  advanced  simulation  technology 
(MMI,  database  management,  synchronization,  and  after  action  reviews). 

Synthetic  Theater  of  War-Europe  (STOW-E)  was  conducted  Nov.  4-7,  1994  as  part  of 
ATLANTIC  RESOLVE  94  (formerly  REFORGER).  It  linked  Army,  Navy  and  Air  Force  units 
in  each  service's  virtual,  live  and  constructive  simulations  via  the  DSI.  An  example  of  success 
was  that  a  brigade  commander  fought  all  his  live,  virtual  and  constructive  brigades  as  live  with 
the  effects  of  simulated  FI 6s  and  Apache's  appearing  to  be  real.  The  Leading  Edge  Environment 
(LEE)  for  the  Global  Command  and  Control  System  (GCCS)  is  being  worked  within  the 
Advanced  Information  Technology  Services  (AITS)  ARPA/DISA  JPO  with  DMSO  playing  a 
part  because  M&S  will  be  used  as  applications  in  LEEGCCS.  The  objective  is  to  demonstrate 
ARPA  technology  in  an  ACTD  of  fieldable  prototypes  (tools,  environment,  applications)  that 
will  be  used  to  evolve  GCCS  through  eventual  incorporation  of  LEE  products  into  the  GCCS 
core. 

Joint  Simulations  (JSIMS)  will  define  a  system  architecture,  services,  development  standards, 
and  validation  standards  to  ensure  distributed-developed  software  is  interoperable.  The  JSIMS 
concept  is  for  the  services  to  leverage  ARPA  advanced  technology  in  developing  software  to 
meet  service-unique  requirements  in  accord  with  the  evolving  JSIMS  requirements  and 
standards.  An  objective  is  to  develop  joint  and  common  objects  that  can  be  interoperable  and 
reused.  JSIMS  will  form  the  technical  standards  and  requirements  umbrella  under  which  the 
services  will  build  their  advanced  simulations:  WARSIM  (Army),  NASM  (Air  Force),  and  NSS 
(Navy).  The  M&S  Master  Plan  technical  framework  forms  a  larger  umbrella  over  mission  space 
domains  that  encompasses  engineering,  manufacturing,  etc.— much  more  than  the  warfighting 
battlespace. 

Dr.  Chien  Huo:  DoD  M&S  Master  Plan  Update  Modeling  and  Data  Administration 
Program 

Dr.  Huo  summarized  important  recent  DMSO  events:  (1)  Master  Plan  draft  is  out  with  vision, 
objectives,  actions,  schedule  and  responsibilities;  (2)  the  focused  call  process  has  stopped,  (3) 
DMSO  investments  will  focus  on  execution  of  the  Master  Plan;  and  (4)  the  10th  DRTWG 
Conference  will  be  held  August  1-4, 1995  at  IDA.  There  was  a  question  about  what  it  meant  to 
stop  the  focused  call  to  Components  for  proposals.  The  answer  was  that  the  Components  have 
representatives  on  the  MSWG  and  the  EXCIMS  and  can  make  their  needs  known  in  those  groups 
to  influence  the  way  DMSO  funds  are  allocated  to  carry  out  the  Master  Plan. 

Dr.  Huo  announced  that  the  DIS  Steering  Committee  has  approved  the  formation  of  a  DIS  Data 
and  Repositories  Special  Interest  Group  (SIG)  which  will  meet  for  the  first  time  during  the  DIS 
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Workshop  in  Orlando,  March  13-17.  The  co-chairs  of  the  SIG  are  Dr.  Huo  and  MAJ  Walt 
Swindell  (USA/TRAC).  Also  in  the  previous  week.  Dr.  Huo  led  a  DoD  C3I  Stakeholders 
Strategic  Planning  meeting  addressing  data  administration  needs  and  that  went  very  well.  He 
sees  a  strong  need  for  the  C3I  community  and  the  M&S  community  (as  well  as  the  intelligence 
community)  to  work  together  on  data  administration  and  standards.  He  said  that  in  implementing 
the  Corporate  Information  Management  plans  there  has  been  a  strong  disconnect  between  the 
operational  world  and  the  technologists.  The  operators  don't  know  what  technology  has  to  offer. 

Dr.  Huo's  vision,  as  the  M&S  FDAd,  is  to  "enable  data  suppliers  to  provide  the  M&S  community 
cost-effective,  timely,  and  certified  data  to  promote  reuse  and  sharing  of  data,  and  to  provide 
interoperability  of  models  and  simulations,  and  improved  credibility  of  modeling  and 
simulation  results."  His  view  is  that  process  modeling  for  requirements  definition  and 
traceability  will  become  the  primary  means  of  communication  between  users  and  developers.  It 
will  be  the  cornerstone  of  acquisition  documentation,  and  be  needed  to  recognize  a  common 
technical  framework  for  C4I  and  M&S. 

The  DRTWG  was  organized  to  respond  to  the  real  world  challenges  of  data  that  is  non-standard 
and  redundant,  has  no  recognized  responsible  authoritative  source,  and  is  lacking  in  data  security 
policy  and  technology  required  to  support  data  reuse  and  sharing.  Furthermore,  data  collection 
and  dissemination  is  labor-intensive  and  costly  and  is  missing  verification  and  validity  checks 
and  documentation  of  such.  The  main  needs  of  the  M&S  community  are  for:  (1)  a  repository 
system  that  can  manage  all  M&S  information  products  (e.g.,  metadata/data  standards;  data  and 
databases;  reusable  algorithms  and  models  and  simulations;  and  common  tools);  (2)  common 
standards  for  complex  data,  nomenclature  and  symbology;  (3)  data  verification,  validation  and 
certification;  and  (4)  data  security. 

The  M&S  Master  Plan  and  supporting  Investment  Plan  are  guiding  DMSO’s  short-term  and  long¬ 
term  initiatives.  Master  Plan  draft  comments  received  from  OSD,  CINCs,  Services,  industry  and 
individuals  identified  data  as  a  critical  problem  that  was  not  given  enough  emphasis.  This 
resulted  in  data  standards  being  brought  forward  as  a  part  of  Objective  #1.  The  M&S  Master 
Plan  establishes  specific  milestones  for  (1)  data  standardization;  (2)  data  W&C  in  coordination 
with  M&S  VV&A;  (3)  developing  a  distributed  MSRR;  (4)  establishing  authoritative  data 
sources;  and  (5)  defining  data  security  requirements. 

The  main  DMSO  DA  activities  are:  (1)  FDAd  DA  plans  and  activities;  (2)  developing  the  M&S 
Community  Directories  (to  databases,  models  and  simulations,  and  authoritative  data  sources), 

(3)  DRTWG  semi-annual  meetings;  (4)  Task  Forces  for  Data  VV&C,  Data  Standards,  Data 
Security  Requirements  and  Repositories  and  several  Subgroups  (Data  VV&C  Guidelines, 
Authoritative  Data  Sources,  Complex  Data). 

The  mission  of  the  M&S  data  administration  program  is  to  first:  establish,  promulgate,  and 
oversee  policies,  procedures,  and  methodologies  for  functional  data  requirements,  data  standards, 
data  quality  (data  verification,  validation  and  certification)  and  data  security.  These  will  form  the 
general  guidance  for  use  of  data  in  environmental,  systems,  and  human  behavior  common 
representations  for  M&S.  Secondly,  to  develop  a  distributed  repository  system  to  serve  M&S 
clients  in  developing  and  using  M&S  and  accessing  and  retrieving  data  at  multiple  security 
levels.  The  M&S  Resource  Repository  (MSRR)  project  will  define  a  distributed  MSRR  minimal 
architecture  compliant  with  the  DISA  Technical  Architecture  Framework  for  Information 
Management  (TAFIM)  and  industry  standards.  M&S  community  organizations  needing  to 
develop  a  new  data  center,  database,  reuse  repository,  etc.  will  be  encouraged  to  make  their 
repository  compliant  with  the  MSRR  minimal  architecture  to  encourage  greater  interoperability 
and  sharing  of  service  and  application  code  and  tools. 
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Ms.  Linda  Calvert:  Status  of  Data  Standardization 

To  carry  out  DA  activities,  the  M&S  FDAd  has  established  a  support  group  at  DMSO  in 
Washington  that  is  currently  led  by  Ms.  Linda  Calvert  and  a  group  at  Ft  Huachuca  led  by  the 
JDBE  project  manager,  Ms.  Janet  McDonald.  The  Washington  DA  organization  will  be 
coordinating  with  Component  M&S  offices  to  provide  DA  support  to  the  M&S  community. 

The  kinds  of  activities  the  DA  organizations  provide  to  the  FDAd  are:  (1)  representing  him  at 
his  request  on  functional  issues  affecting  M&S;  (2)  providing  input  to  him  on  functional  area 
issues;  (4)  working  towards  streamlining  the  8320  data  standardization  process;  (4)  planning  and 
budgeting  DA  resources;  (5)  aiding  in  preparing  and  submitting  the  M&S  Data  Administration 
Strategic  Plan  (DASP)  to  DoD;  (6)  aiding  in  the  development  of  M&S  Master  Plan  inputs;  and 
(7)  aiding  in  the  development  of  M&S  DA  policy  and  procedures. 

Operational  services  provided  by  both  the  DMSO  and  JDBE  teams  include:  ( 1 )  assisting  in 
prioritizing  M&S  DA  efforts  and  in  conducting  functional  and  technical  reviews  of  M&S  and 
DoD  data  standards  proposal  packages  and  process  and  data  models;  (2)  providing  training  to  the 
M&S  community;  (3)  participating  in  functional  process  improvement;  (4)  assessing  the  M&S 
DA  program;  and  (5)  facilitating  information  exchange  (e.g.,  through  the  DRTWG  portion  of  the 
M&S  Information  System  and  its  implementation  on  WWW). 

Technical  activities  include:  (1)  assisting  in  developing  M&S  process  and  data  models  and  M&S 
model  integration;  (2)  participating  in  DoD  collaborative  data  modeling  efforts  to  extend  the 
DoD  Data  Model;  (3)  identifying  unique  M&S  data  requirements  (e.g.,  complex  data, 
reengineering  of  data);  (4)  technically  contributing  to  DRTWG  Task  Forces  and  Subgroups  in 
relevant  areas  of  expertise;  (5)  participating  in  relevant  standard  and  other  technical  committees 
and  organizations  to  further  M&S  data  related  goals;  and  (6)  participating,  at  DMSO's  request,  in 
furnishing  data  expertise  to  relevant  M&S  activities  such  as  STOW  97,  LEEGCCS,  JSIMS. 

Near-term  DA  products  include  a  strawman  "to  be"  support  for  8320  data  standardization  process 
in  the  M&S  community;  an  M&S  DA  Policy  Instructions  and  DA  Procedures  Manual  and  the 
M&S  DASP. 

JDBE  standardization  efforts  include: 

—  Development  and  testing  of  the  JDBE  M&S  Methodology  for  producing  data  models 

—  Submitting  candidate  standard  data  elements  to  M&S  FDAd  based  on  data  models 

—  Development  of  formal  training  course  and  training  of  over  100  M&S  people 

—  Publication  of  JDBE  Methodology  Manual 

—  Development  of  Subject  Area  Information  (SAI)  model  for  electromagnetics 

—  Support  for  M&S  FDAD  in  reviewing  over  40  DoD  proposal  packages 

—  Establishment  of  Interim  MSRR  - 

—  Support  for  M&S  client  projects,  including  CENTCOM,  UTSS,  and  BFTT 

Based  on  the  Master  Plan,  DoD  Directives,  and  priority  projects  such  as  STOW-97,  the 
preliminary  priorities  for  developing  data  standards  are  for  C3I  data  and  environmental 
representation  data. 

Summary: 

1.  M&S  FDAd  and  support  organizations  are  in  place  and  operational 

2.  M&S  DA  Policy  and  Procedures  (Draft)  will  be  released  in  FY95 

3.  M&S  data  model  proposal  packages  are  in  pipeline  and  will  be  submitted  to  DoD  DA 
over  next  12  months  in  accord  with  M&S  Master  Plan  schedule 

4.  M&S  DA  Standards  Task  Force  will  coordinate  data  standardization  efforts  across  M&S 
community 
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Discussion: 

Ms.  Calvert  said  that  they  need  help  from  the  M&S  organizations  in  prioritizing  the  M&S  DA 
efforts.  Component  approval  of  the  Master  Plan  is  expected  in  fall  of  1995.  Ms.  Lana  McGlynn 
offered  the  Army's  tool  for  tracking  data  element  standards  development  and  submission  of 
proposal  packages.  It  is  already  on  the  agenda  for  the  MSRR  project  to  look  at  the  Army  tools  as 
part  of  tool  selection.  Someone  else  in  the  audience  said  that  they  didn't  have  a  tool  that  would 
allow  them  to  review  the  data  standards  packages;  JDBE  responded  saying  such  a  tool  is 
available  through  their  WWW  page. 

Some  JDBE  experience:  (1)  historical  experience  in  simulating  electromagnetic  environments; 
(2)  have  reversed  engineered  about  6  target  simulation  systems  for  the  UTSS  project;  and  (3) 
have  provided  training  to  BE  IT. 

Gary  Lambert  (JDBE)  said  that  50%  of  the  entities  they  needed  for  CENTCOM  were  in  the 
DDRS  and  could  be  reused.  However,  95%  of  entities  and  attributes  in  the  DDRS  are  in  the 
developmental  state.  It  is  hard  to  use  the  DDRS  because  it  lacks  a  taxonomy.  It  is  hard  to  find 
things  to  reuse  and  hard  to  determine  which  are  duplicates  or  differ  slightly. 

Someone  from  DIA  said  they  were  uncomfortable  submitting  data  elements  into  an  unclassified 
repository  and  so  won't  be  doing  so.  However,  other  people  in  the  audience  said  that  they  will  be 
submitting  DIA  data  elements  along  with  the  rest  of  their  data  elements. 

Mr.  Paul  Foley:  Perspectives  on  Environmental  Data 

Mr.  Foley  represented  the  DMSO  Environmental  Representation  Technology  Working  Group 
(ERTWG).  He  used  an  overview  chart  to  show  us  all  the  environmental  data  project  activities 
and  standardization  activities  that  they  need  to  coordinate  with.  These  are  listed  below. 

Environmental  data  project  activities: 

—  Joint  Warfare  Simulation  Object  Library  (JWSOL) 

—  Joint  Task  Force-Advanced  Technology  Demonstration  (JTF-ATD) 

—  Dynamic  Environmental  Effects  Model  (DEEM)  (Argonne  Labs) 

—  Environmental  Effects  in  Distributed  Interactive  Simulation  (E2DIS) 

—  Master  Environmental  Library  (MEL)  (kickoff  is  next  week) 

Standardization  Activities: 

—  IEEE/DIS  process  (Environmental  WG  (land,  sea  and  atmosphere)  and  PDUs) 

—  Federal  Geographic  Data  Committee  (FGDC) 

•  Spatial  Data  Transfer  Standards  (FIPS  173) 

•  Content  Standards  for  Digital  Spatial  Metadata 

—  Defense  Standardization  Program  MCGT  area 

—  Digital  Geographic  Information  Working  Group  (DGIWG) 

—  Tri-Service  CAD/GIS  Working  Group 

The  ERTWG  goal  is  to  get  most  environmental  executive  agents  in  place  by  May,  1995.  So  far, 
DMA  has  been  designated  the  executive  agent  for  terrain. 

JWSOL  has  had  DMSO  funding  and  now  is  supported  by  ARPA.  Charles  Herring  has  been  a 
central  person  on  the  project.  He  will  be  coming  to  DMSO  and  they  expect  him  to  introduce 
some  commonality  across  the  DMSO  environmental  projects. 

Mr.  Foley  went  through  the  Argonne  Lab  project  taxonomies.  First,  he  addressed  the  Object 
Management  Working  Group  Environmental  Taxonomy  which  is  quite  detailed  but  at  the  macro 
level.  He  then  went  through  their  DEEM  object  schema  (micro  combatant  level).  DEEM  has 


-20- 


taken  some  categories  and  broken  them  into  subsets  (e.g.,  surface  cover)  for  rendering  algorithms 
to  show  environmental  effects. 

He  believes  that  they  need  for  DoD  to  describe  the  data  elements  in  the  environmental  area 
(which  is  what  DoD  has  attempted  to  do  with  the  DMA  collaborative  data  modeling  effort  but 
have  found  it  is  very  expensive  and  time  consuming).  He  also  said  that  the  DIA  MHDS  database 
is  being  replaced  by  the  MEDB  and  that  needs  to  be  based  on  a  data  model.  (The  DIA  people  in 
the  audience  were  not  able  to  confirm  or  deny  that  the  MIDB  will  be  based  on  a  data  model.) 

He  thought  that  solving  the  data  model  differences  will  be  easy  but  that  if  applications  do  not 
code  the  environment  consistently,  then  there  will  still  be  a  problem  in  exchanging 
environmental  data. 

Mr.  Foley  said  that  currently  there  is  no  central  location  for  all  the  different  environmental  data 
dictionaries  and  he  listed  eight  of  these.  The  Feature  and  Attribute  Coding  Catalog  (FACC)  was 
developed  by  an  international  committee  under  DIGEST.  It  is  a  dynamic  catalog,  DMA  is  using 
it  as  well  as  other  organizations  and  it  may  form  a  base  standard.  Dave  Danko  explained  that  the 
Feature  and  Attribute  Coding  System  (FACS)  is  an  internal  DMA  schema  for  internal  digital 
system  use  and  has  been  used  by  Project  285 1  as  a  basis  for  a  Combined  Terrain  Information 
System  (CTIS).  The  DMA  Feature  File  (DMAFF)  is  an  older  DMA  scheme  and  there  needs  to 
be  mapping  developed  from  that  to  FACC.  The  Digital  Line  Graph-Enhanced  (DLG-E)  is 
feature  based  and  differs  from  the  earlier  line  based  scheme  but  there  are  differences  between  it 
and  FACC.  Other  data  dictionary  schemes  include  Binary  Universal  Format  for  the 
Representation  of  meteorological  data  (BUFR),  TRI-Service  CAD/GIS  Standard,  and 
Topologically  Integrated  Geographic  Encoding  and  Referencing  (TIGER)  (Census  Bureau).  In 
DoD,  there  are  also  many  project  unique  type/status  coding  structures. 

Mr.  Foley  also  discussed  DoD  Policy  Memo  95-1  that  establishes  the  requirement  for  waivers  to 
use  MIL-STDS/SPECS  in  contract  solicitation.  As  a  result,  DMA  as  manager  for  the  MCGT,  is 
converting  all  MIL-STDS  to  interface  standards  and  MIL-SPECS  to  performance  specifications. 

Dr.  Randy  Garrett:  STOW-97  Briefing 

Dr.  Garrett  supports  COL  Bob  Reddy  in  the  ARPA  Advanced  Distributed  Simulation  Program. 
STOW-97  is  the  largest  one  often  ADS  programs.  ADS  features  are  virtual  simulations,  entity- 
based  (dealing  with  weapons  and  system  platforms),  3-D  based  (using  3-D  terrain)  and  inherently 
distributed.  Reasons  for  the  STOW  program  are  (1)  wide  variety  of  changing  threats  from  mid¬ 
intensity  to  operations  other  than  war;  (2)  increased  focus  on  maneuver,  synchronization,  agility 
and  C2;  (3)  importance  of  joint  and  combined  warfare;  (4)  the  requirement  for  a  high  state  of 
readiness;  and  (5)  a  reduction  in  defense  resources.  Current  simulations  don't  meet  DoD  current 
needs.  They  focus  on  smaller  scale  operations.  Additionally,  technology  today  can  support 
STOW  whereas  it  couldn't  have  ten  years  ago. 

The  program  goals  are  to:  (1)  improve  the  quality  of  simulations  beyond  cuirent  state-of-the-art 
(entity  resolution  and  performance,  and  environmental  representations);  (2)  improve  simulation 
training  effectiveness  and  flexibility  (by  interfacing  M&S  with  operational  C4I);  (3)  reduce 
overhead  costs  of  simulation  (knowledge-based  SAFORS,  faster  database  builds,  improved 
information  transfer);  (4)  improve  after  action  analytical  tools;  and  (5)  achieve  simulation  driven 
mission  rehearsal  IOC. 

The  STOW  Concept  of  Operations  is  that  as  STOW-97  simulations  are  demonstrated,  they  can 
actually  reside  at  ACOM  and  live  there  for  two  years  during  which  they  will  be  used 
operationally.  There  will  be  engineering  demonstrations  in  the  fall  of  each  year  to  get  to  STOW- 
97,  the  first  was  STOW-E  in  November  1994.  STOW-97  will  address  USACOM  rehearsal 
challenges.  At  the  top  of  the  list  is  operational  crisis  planning  resulting  in  rehearsals  and 
operational  C4I.  There  is  a  strong  linkage  between  STOW  data  and  STOW  technology 
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development.  STOW  is  emphasizing  object  libraries  not  particularly  for  reuse  but  for 
determining  interoperability.  The  concept  is  that  objects  will  register  their  attributes  and  the 
library  will  also  contain  algorithms  that  calculate  object  to  object  interactions.  They  would  like 
to  move  closer  to  the  CORB  A  concept  of  an  object  broker.  STOW  simulation  performance 
requires  algorithms  and  data  at  multiple  resolution  levels.  STOW  will  be  focusing  more  on  the 
individual  soldier  level,  new  systems  such  as  logistics  and  intelligence,  and  linkage  to  real  world 
data  sources  such  as  weather,  intel,  and  log  data. 

The  areas  that  need  emphasis  are:  dictionaries  of  objects  and  object  attributes  (including 
algorithms  for  environmental  interactions  and  behavioral  descriptors  for  OPFOR  and 
individuals);  environmental  representation  data  (to  support  terrain  reasoning,  sensor  interactions, 
computational/network  load  tradeoffs);  intelligence-oriented  data  for  entities;  and  real  world  data 
(sources,  formats,  links)  in  areas  such  as  transportation  and  logistics. 
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3.4  REPORT  FROM  INTELLIGENCE  FDAD 

Mr.  Jim  Davidson:  Data  Standardization  to  Achieve  Interoperability 

The  issue:  DoD  has  efforts  underway  to  model  and  standardize  data  to  meet  interoperability 
objectives  and  support  the  warfighter  which  if  they  were  realized  would  improve  joint 
interoperability  at  reduced  cost  and  risk.  But:  no  single  data  standard  reflects  the  data  needs 
across  the  C3I  community;  data  standardization  is  a  lengthy  process;  all  DoD  systems  cannot  be 
modified  in  the  near-term  to  support  a  single  standard  because  of  cost;  and  inadequate  training 
exists  for  use  of  evolving  data  standards  and  support  tools.  An  opportunity  exists  to  influence 
data  standardization  through  the  migration  system  process. 

Convergence  is  not  occurring  rapidly:  MUDS  IDB/MIDB  is  an  intel  standard  but  not  supportive 
of  tactical  ground  operations  and  equipment  and  personnel  operating  parameters  are  not 
consistent  with  the  C2  Core  Model;  the  DISA/JIEO  C2  Core  Model  lacks  intel-unique  elements 
and  not  all  data  elements  have  been  fully  standardized.  On  the  other  hand  he  pointed  out  that 
USMTF  data  elements  are  a  joint-level  standard  supporting  tactical  operations,  the  data  elements 
can  be  used  outside  of  messages,  and  they  support  many  legacy  as  well  as  migration  systems; 
and  Variable  Message  Formats  are  planned  for  use  by  Army  tactical  systems  using  Army  tactical 
communications.  [NOTE  FROM  IRIS,  THOUGH  DAVIDSON  IS  IMPRESSED  WITH  THE 
MESSAGE  SYSTEMS,  THERE  ARE  MANY  INHERENT  PROBLEMS  WITH  THEM  (I  DID 
A  USMTF  STUDY  LAST  YEAR  SO  FEEL  FREE  TO  ASK  ME  ABOUT  THE  PROBLEMS). 
FOR  ONE  THING,  THE  DATA  ELEMENTS  ARE  NOT  BASED  ON  A  DATA  MODEL  AND 
ARE  NOT  STANDARD  THUS  REQUIRING  MUCH  TRANSLATION  TO  MESSAGES 
FROM  DATABASES  AND  VICE  VERSA.  THE  USMTFS  UNDERGO  300-500  CHANGES 
PER  YEAR,  REQUIRING  OVER  2  YEARS  TO  GET  NEW  CHANGES  INTO  THE  SYSTEM 
BECAUSE  SOFTWARE  CHANGES  TO  TRANSLATORS  ARE  REQUIRED  WHICH  IN 
TURN  REQUIRES  REACCREDITATION  OF  SYSTEMS.] 

Today  some  interoperability  exists  within  groups  of  systems  with  a  common  domain  via  direct 
data  sharing  and  standard  messages  and  between  system  domains  via  standard  messages.  The 
final  solution  of  a  single  data  standard  used  within  and  between  all  systems  is  infeasible  because 
of  the  large  number  of  disparate  DoD  systems.  The  recommended  strategy  is  to  identify  and 
prioritize  systems  requiring  enhanced  interoperability  and  evolve  high  priority  systems  to 
coordinated  data  standards  more  quickly  facilitated  by  reusable  software,  translator  technology, 
database  warehousing  concept  and  schema  brokering.  He  recommends  ensuring  sufficient 
resources  are  applied  to  the  C2  Core  Model  and  MIDB  definitions  to  achieve  consistency  and 
then  mandate  this  data  standard  for  all  migration  system  efforts.  His  recommendations  included 
boosting  training  programs. 

Mr.  Davidson  was  also  concerned  (as  we  have  been)  with  putting  legacy  data  elements  into  the 
DDRS  without  them  having  been  data  modeled.  He  said  that  about  20%  of  unmodeled  intel  DEs 
have  been  entered  this  way.  They  also  have  problems  entering  data  elements  into  an  unclassified 
DDRS  and  will  be  developing  a  classified  version  that  will  be  a  superset  of  the  unclassified 
DDRS.  He  hopes  to  have  this  accomplished  by  summer  1995.  The  briefing  he  gave  to  us  has 
been  given  to  Mr.  Paige. 
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3.5  REPORTS  FROM  DRTWG  TASK  FORCES  AND  SUBGROUPS 

Mr.  Bob  Hartling  and  Mr.  Mark  Ralston:  Data  W&C  Guidelines  Subgroup  Report 

Mr.  Bob  Hartling  briefly  discussed  related,  concurrent  efforts  that  are  being  coordinated  with  this 
Subgroup  effort.  They  are:  the  DMSO  Distributed  Simulation  VV&A  Study  (led  by  Ms.  Pam 
Blechinger),  the  DIS  Workshop  VV&A  WG  led  by  Ms.  Simone  Youngblood,  and  the  MORS 
SIMDATAM  Workshop  which  will  take  place  March  28-29th  and  will  have  a  WG  on  VV&C  in 
Databases. 

Mr.  Jeff  Rothenberg  (RAND)  is  contributing  to  the  VV&C  effort  by  defining  a  database/dataset 
quality  profile  that  may  include  metadata  about  the  data  at  the  database,  data-element  and  data 
value  levels  as  well  as  providing  an  audit  trail  of  data  derivation.  It  will  serve  both  user  and 
supplier/producer  data. 

The  focus  of  the  VV&C  Subgroup  is  on  development  of  W&C  process  guidelines  that  will 
eventually  lead  to  a  DoDI.  DMSO  is  funding  this  FY95  effort  that  is  being  led  by  Mr.  Mark 
Ralston  (US  A/ AMS  A  A)  to  produce  initial  draft  guidelines  that  are  useful  and  practical  by  the 
end  of  the  year.  These  will  be  followed  by  an  improved  version  the  following  March  and  pilot 
studies  in  1996.  Three  tasks  have  been  laid  out  that  include  EDEFO  process  modeling  of 
Components'  representative  V&V  processes.  Task  1,  Guidelines  for  Non-DIS  User  Data  VV&C, 
is  being  led  by  Lt  Col  Denny  Lester  with  participation  from  five  organizations  (Army,  Navy,  Air 
Force,  JS,  and  OSD).  Task  2,  Guidelines  for  DIS  User  Data  VV&C,  will  use  the  results  of  the 
DIS  VV&A/C  effort  led  by  Ms.  Simone  Youngblood  with  data  VV&C  being  addressed  by  Ms. 
Susan  Solick  with  aid  from  Mr.  Jeff  Rothenberg.  Task  3,  Develop  Guidelines  for  Producer  Data 
VV&C,  is  being  led  by  Mr.  Mark  Ralston  with  five  participating  organizations  (Army,  Navy,  Air 
Force,  DMA  and  DIA). 

The  audience  raised  a  question  about  the  need  for  cost  data.  For  example,  DIS  has  shown  that 
for  a  10%  investment  one  can  get  good  M&S  VV&A.  Mr.  Ralston  agreed  to  try  to  collect  cost 
data  and  insights  while  carrying  out  Task  3. 

Mr.  Mike  Hopkins:  Authoritative  Data  Sources  Subgroup 

The  Authoritative  Data  Sources  (ADS)  Subgroup  was  started  a  year  ago  to  (1)  identify  ADS  and 
develop  an  ADS  directory  and  (2)  address  the  relationship  between  data  sources,  data  centers  and 
M&S  data  users.  Last  April  the  ADS  Subgroup  produced  a  draft  paper,  containing  some  initial 
data  sources,  as  a  first  attempt  to  determine  and  describe  the  magnitude  of  the  task.  Currently, 
they  have  been  concentrating  on  (1)  developing  a  taxonomy  for  identifying  ADS  and  for 
accessing  the  ADS  directory,  (2)  defining  their  terms,  (3)  developing  the  ADS  directory  data 
model  (which  is  to  be  integrated  with  the  Database  and  M&S  data  model)  and  (4)  addressing 
how  to  populate  the  ADS.  Future  plans  are  to  (1)  finalize  the  taxonomy  and  use  it;  (2)  finalize 
the  definitions;  (3)  develop  an  approach  for  surveying  the  community  to  identify  ADSs;  (4) 
finalize  the  ADS  document  that  describes  responsibilities  and  roles  of  ADSs,  data  centers  and 
users,  and  includes  guidelines;  and  (5)  define  to  the  Data  Security  Requirements  Task  Force  how 
data  centers  exchange  data  with  other  centers  and  release  data  to  users  (data  aggregation  and 
release  issues). 

Tasks  with  FY95  DMSO  support  for  the  Subgroup  and  CENTCOM  are  to:  (1)  identify  ADSs 
(includes  developing  data  survey,  taxonomy  and  collection);  (2)  develop  ADS  directory  and 
support  it  via  the  Interim  MSRR  WWW  interface;  (3)  develop  an  exportable/reusable  data 
quality  engineering  tool  based  on  CENTCOM's  current  tool  (supported  by  DMSO);  and  (4) 
integrate  the  CENTCOM  databases  data  model  with  the  C2  Core  Data  Model. 
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The  ADS  is  available  in  raw  form  via  the  Interim  MSRR  WWW  at  JDBE;  a  word  perfect  copy  is 
also  available.  The  Defense  Manpower  Data  Center  has  told  the  Subgroup  that  they  may  use  the 
DMDC  catalog.  An  issue  is  whether  catalogs  should  be  duplicated  on  the  ADS  or  the  ADS 
should  furnish  pointers  to  existing  catalogs.  The  latter  is  probably  preferable  since  the 
maintenance  of  the  catalogs  is  then  assumed  by  the  owners  and  not  by  the  M&S  community. 

Ms.  Iris  Kameny  (for  Ms.  Lunt  and  Dr.  Huo):  Data  Security  Requirements  Task  Force 

1)  pnAi*t 

This  is  the  newest  Task  Force.  It  held  its  first  meeting  on  December  14, 1994  attracting  over  50 
attendees  from  industry,  government  and  FFRDCs.  The  objectives  of  the  task  force  are  to  (1) 
provide  a  forum  for  identification  and  discussion  of  M&S  data  security  issues  and  (2)  to 
organize,  analyze  and  translate  M&S  data  security  issues  into  requirements  during  FY96.  Data 
security  policy  requirements  will  be  presented  to  the  DMSO  Director  to  work  upwards  through 
DoD  Data  security  technology  requirements  will  be  addressed  by  the  ARPA/CSTO  Information 
Security  Program  led  by  Ms.  Teresa  Lunt.  The  ARPA  objectives  in  participating  in  this  TF  are 
(1)  to  use  the  forum  to  match  up  database  security  technology  players  with  M&S  players  and  (2) 
to  use  M&S  data  security  requirements  to  plan  testbed  projects  involving  M&S  users  having 
problems  and  experimental  database  security  technology  as  possible  solutions. 

Ms.  Kameny  collected  initial  M&S  data  security  issues,  documented  them  in  a  white  paper  and 
briefed  them  at  the  December  14th  meeting.  They  covered:  data  exchange  and  access,  data 
aggregation;  classification  of  enumerated  values;  protection  of  data  source  in  downgrading  data; 
releasability  of  data/information;  standardized  security  labels;  multilevel  secure  DIS  exercises; 
and  a  DIS  component  participating  in  exercises  at  different  security  levels.  A  policy  related  issue 
is  the  trade-off  between  protecting  data  and  the  need  to  interoperate  and  share  data  among  DoD 
organizations.  This  is  becoming  an  important  issue  as  connectivity  and  interoperability  needs 
increase. 

Mr.  Terry  Mayfield  (IDA)  will  be  Ms.  Lunt's  POC  for  this  TF  and  Ms. 

Iris  Kameny  will  be  Dr.  Huo's  POC  for  this  TF. 

Mr.  Jim  Augins  and  Mr.  Pete  Valentine:  Repositories  Task  Force 

The  objectives  of  the  Repositories  Task  Force  are  to:  (1)  define  a  minimal  common  architecture 
for  M&S  community  repositories  for  managing  data  standards  and  metadata,  data,  models  and 
simulations,  algorithms,  and  common  tools;  (2)  identify  requirements  and  solutions  for  M&S 
repositories;  (3)  investigate  the  applicability  of  DoD,  Component  and  industry  ideas,  COTS  and 
GOTS  solutions;  (4)  and  provide  a  forum  for  review  of  progress  and  related  activities  of  the 
M&S  repository  community. 

The  Sub-objective  5-3  of  the  M&S  Master  Plan  is  to  provide  a  repository  system  to  facilitate 
developer  and  end-user  access  to  M&S  resources.  "DoD  must  establish  a  distributed  system  of 
M&S  Resource  Repositories  (MSRRs)  to  efficiently  and  effectively  provide  the  community  with 
timely,  verified,  and  validated  data,  metadata,  algorithms,  models,  simulations  and  tools.  The 
MSRRs  should  also  provide  background  information  (e.g.,  model  assumptions,  source  of  data, 
classification  of  data,  range  of  validity  of  algorithms,  VV&A/C  history).  This  will  promote  reuse 
and  sharing  of  M&S  resources  and  will  improve  credibility  of  M&S  results.  These  repositories 
will  provide  tools  for  configuration  management  and  for  accessing,  browsing,  and  retrieving 
M&S  resources." 

The  Master  Plan  actions  are  to  develop  an  Interim  MSRR  in  FY95;  complete  MSRR 
requirements  by  2Q96;  complete  prototype  MSRR  by  2Q97;  provide  limited  operational  testbed 
by  2Q98;  initiate  DoD- wide  distribution  in  FY99  and  complete  the  distribution  in  2000.  There 
are  also  actions  to  develop  authoritative  data  sources  and  implement  the  initial  ADS  directory  as 
part  of  the  Interim  MSRR  in  FY95,  and  to  develop  prototype  configuration  management  tools  by 
2Q97  and  included  them  in  the  limited  operational  testbed  by  2Q98. 
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To  carry  out  these  activities,  the  Repositories  TF  met  during  August,  October  and  December  to 
specify  an  MSRR  Project  that  encompasses  the  following  tasks: 

Task  1 :  MSRR  Framework  and  Concept:  CONOPS,  process  and  data  models 
Task  2:  MSRR  Functional  Requirements  and  Specifications,  including:  MSRR 

configuration  management  requirements,  architectural  and  network  requirements 
Task  3:  MSRR  Design  Studies  and  Tradeoffs:  top  level  design  and  tradeoffs 

Task  4:  Interim  MSRR:  information  exchange  based  on  WWW  standards  and  interim 
support  for  M&S  FDAd 
Task  5:  Support  to  DRTWG 

Work  in  progress  includes:  (1)  MSRR  road  map;  (2)  identification  of  MSRR  prototype  object 
set-  (3)  draft  meta  model  to  support  the  8320  process  for  submission  of  data  elements;  (4) 
identification  of  TF  security  concerns;  (5)  addressing  MSRR  WWW  information  exchange 
architecture  and  standards;  and  (6)  coordinating  with  DISA  on  their  new  repository  effort. 

FY95  objectives  are  to:  (1)  develop  MSRR  framework  and  concepts;  (2)  write  MSRR  functional 
and  architecture  requirements  document;  (3)  write  MSRR  top  level  design  document;  and  (4) 
write  a  WWW  standards  manual  for  information  exchange. 

Current  status:  the  Interim  MSRR  is  operational  and  supported  by  JDBE  at  Ft.  Huachuca.  It 
includes  access  to  the  initial  raw  form  of  the  ADS  directory  information. 

Mr.  Peter  Valentine  and  Mr.  Jim  Augins:  WWW  Implementation  Plans 

The  Interim  MSRR  can  contain  directories/catalogs;  metadata;  instance  databases;  algorithms; 
M&S  and  tools.  The  Interim  MSRR  WWW  architecture  will  be  distributed,  modular, 
client/server,  low  cost  and  will  operate  in  heterogeneous  environments  (all  major  platforms: 
UNIX/POSIX,  DOS/WINDOW,  Mac  System  7  and  servers  to  include  Windows/NT).  When  a 
WWW  client  wants  to  communicate  with  a  WWW  server,  it  sends  a  request  to  the  server  in  the 
form  of  a  URL  (Universal  Resource  Locator)  which  identifies  which  "Page"  on  the  server  it 
would  like  to  retrieve.  The  server  in  turn  passes  the  contents  of  the  file  referenced  by  the  URL  to 
the  client.  Usually  these  files  are  HTML  (Hyper  Text  Markup  Language)  "Pages."  HTML  is  a 
subset  of  the  government  standard  SGML  (Standard  Generalized  Markup  Language).  HTML 
documents  can  be  created  with  a  simple  text  editor,  or  with  a  number  of  shareware  or 
commercial  tools.  HTML  documents  can  contain  formatted  text,  in-line  graphics,  sound,  multi- 
media  and  links  to  other  WWW  Pages  or  resources.  URLs  can  point  to  other  resources  such  as: 
Gopher  servers,  E-Mail  addresses,  WAIS  gateways,  or  data  files  via  FTP  or  HTTP .  Other 
services  the  MSRR  will  provide  are:  WAIS  catalogs,  E-Mail,  Gopher,  FTP,  NewsGroups, 
Internet  Relay  Chat  (IRC)/MUD-Object  Oriented  (MOO),  video  conferences  and  Groupware. 

The  first  Interim  MSRR  node  is  at:  http://huchuca-jdbe.army.mil/ 

Related  NRaD  node:  http://netmon2.nosc.mil/reposwg/jimswg.html 

The  DMSO  gopher  M&S  Information  System:  gopher://gopher.dmso.mil:70/l 

The  TWISTIAC:  http://www.tiig.ist.ucf.edu/ms_web/ms_web.html. 

During  FY95,  there  are  plans  to  bring  additional  Interim  MSRR  nodes  up  at  USA/TRAC, 

NRaD/ ARMS,  CENTCOM,  and  JWFC. 

Ms.  Linda  Calvert  and  MAJ  Walt  Swindell:  Data  Standards  Task  Force 

The  Data  Standards  Task  Force  started  up  in  February  1994  as  a  result  of  the  MORS 
SIMDATAM  recommendation  for  such  a  group  but  it  has  not  been  very  active.  Rather  its  two 
Subgroups,  Repositories  (which  has  now  become  a  Task  Force)  and  DIS  Data  Standards,  have 
been  active.  The  M&S  FDAd  has  decided  to  make  the  Complex  Data  TF  a  Subgroup  under  the 
Data  Standards  TF  and  to  reconvene  the  Data  Standards  TF  to  address  a  new  agenda.  Ms.  Linda 
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Calvert  is  working  on  a  charter  for  the  Data  Standards  TF  and  will  identify  priorities  for  a 
proposed  agenda  that  includes:  reviewing  M&S  DA  Policy  and  Procedures;  refining  the  8320 
data  standardization  process  for  M&S;  defining  complex  data;  modeling  of  complex  data,  and 
use  of  modeling  tools.  The  first  meeting  for  this  revitalized  TF  is  planned  for  April 
1995. 

The  outcome  of  the  DIS  Subgroup  was  a  collaborative  paper  "DIS  Need  for  DoD  Data 
Standards"  (authored  by  Iris  Kameny,  Walt  Swindell,  Luci  Haddad,  Peter  Valentine  and  Jim 
Watson)  which  was  presented  at  the  1 1th  DIS  Workshop  on  Standards  for  the  Interoperability  of 
Defense  Simulations,  26-30  September  1994  to  the  working  groups  on  Fidelity,  Management  and 
Usability;  VV&A;  Fidelity  Descriptions  Requiring  Logistics;  and  Computer  Generated  Forces. 
The  paper  covered:  evolution  of  data  standards;  DIS  vision  and  its  void  wrt  use  of  data 
standards;  ways  data  standards  can  benefit  DIS;  the  data  standardization  process;  DIS  data 
modeling;  future  vision  of  DIS  with  data  standards,  and  DIS  roadmap  to  data  standardization. 

The  roadmap  to  DIS  data  standardization  included:  education;  process  modeling  of  DIS 
CONOPS;  guidelines  for  performing  standardization;  cataloging  and  prioritizing  data 
requirements  by  functional  areas;  implementing  data  standards  in  that  order;  and  developing 
configuration  management  for  maintenance. 

A  recommendation  was  to  form  a  DIS  Data  and  Repositories  SIG  with  the  objective  to  make 
recommendations  to  the  DIS  community  on  requirements  for,  and  use  of,  DoD  data  standards 
and  repositories.  It  would:  define  DIS  functional  area  requirements  for  data  standards  to  be 
compliant  with  DoD  data  standards  and  relevant  commercial  standards;  define  or  identify 
common  datasets  (authoritative  data  sources)  for  use  in  DIS  exercises;  and  define  DIS 
requirements  for  DIS  MSRRs  compliant  with  the  developing  MSRR  architecture. 

The  Data  and  Repositories  SIG  proposal  was  accepted  by  DIS  and  the  first  meeting  will  be  held 
during  the  12th  DIS  Workshop  March  13-17, 1995.  The  DIS  Data  and  Repositories  co-chairs  are 
MAJ  Walt  Swindell  and  Dr.  Chien  Huo. 
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3.6  REPORTS  FROM  DMSO  FUNDED  PROJECTS 

Mr.  Robert  Helsel:  Modeling  and  Simulation  Information  Management  (MSIM) 

M&S  data  goals  are  to  provide  data  interoperability,  consistency  and  sufficiency  within  and 
across  functional  areas;  maximize  use  of  operational  data  for  instance  fill;  and  maximize 
software  reuse.  In  reality  current  models  are  function  and  system  specific,  stovepipes  exist 
within  functional  areas,  there  is  minimal  data  interoperability  within  and  across  fimctional  areas 
and  there  is  inconsistent  use  of  operational  data.  The  MSIM  objectives  are  to:  improve  M&S  of 
real  world  operations,  eliminate  redundant  data  production,  and  furnish  proof  of  concept  in  the 
C3I  electronic  warfare  area.  Where  electronic  warfare  is  defined  as:  any  military  action 
involving  the  use  of  electromagnetics  and  directed  energy  to  control  the  EM  spectrum  or  attack 
the  enemy.  It  includes  electronic  attack  (EA),  electronic  warfare  support  (ES),  and  electronic 
warfare  protection  (EP). 

The  MSIM  tasks  are: 

94-1:  EW  data  standards  working  meeting:  held  in  October  1994 

94-2:  Survey  of  Service  C2W/IW  M&S  Requirements:  NRaD,  AMSAA  and  AF  S&A 

94-3:  Report:  M&S  Data  Support  Deficiencies:  service  reports  under  development  (1 

March) 

94-4:  Report:  M&S  Data  Elements  (metadata):  service  reports  being  integrated  (15 

February) 

94-5:  Draft  Data  Standardization  Process  Architecture:  in  review  (final  1  March) 

94-6:  Draft  Joint  EW  M&S  Data  Set(s):  due  1  April  1995 

Tasks  94-2,3,4:  identified  data  requirements  for  the  Campaign  Level  using  8  models:  Army: 
VIC,  JANUS,  CASFORUM;  Navy:  ITEM,  CWM;  Air  Force:  Thunder,  Air  Warfare 
Simulation;  and  Joint:  JACUZI  (feeder  into  AF  Warfare  model).  They  identified  450  data 
elements. 

They  are  using  NWTDB  reverse  engineering  tools  and  were  questioned  about  why  they  didn  t 
use  JDBE.  JDBE  has  trained  some  of  the  NWTDB  people  and  they  have  developed  their  own 
reverse  engineering  techniques.  They  have  found  that  M&S  have  data  elements  such  as  for 
performance  that  are  not  found  in  operational  systems  (e.g.,  simulation  entities,  stoptime,  etc.). 
Some  things  are  special  to  each  of  the  three  worlds  they  have  been  looking  at  (M&S,  operations 
and  acquisition).  It  is  difficult  to  make  matches  or  relationships  between  the  data  elements  in  the 
operational  world  and  those  used  in  M&S. 

Task  94-5:  C3I  interoperability:  they  are  preparing  data  element  standardization  for  DDRS 
registration  and  are  running  into  the  CDAd  vs  FDAd  paradigm  where  there  is  a  NWTDB 
functional  view  through  the  Navy  DA  and  a  DMSO  view  through  the  M&S  FDAd.  He  showed  a 
modeling  hierarchy  where  the  DoD  C2  Core  Model  (with  C3I  extensions)  is  a  functional  area 
model  above  the  NWTDB  logical  data  model  (which  they  are  using  as  proof  of  concept)  to 
functional  database  models  (NWTDB  NID,  and  RAP  ADS  segments  for  electronic  warfare), 
down  to  physical  models  (service  campaign  models).  They  have  developed  a  process 
architecture  for  data  standardization  and  an  M&S  data  element  decomposition  flow  to  handle 
complex  data  (derived  data  and  composite  data).  [A  QUESTION  COMES  TO  MIND  WRT 
COMPLEX  DATA  AND  HOW  THEY  ARE  HANDLING  THE  DERIVED  DATA  ELEMENTS 
IF  THAT  IS  WHAT  NEEDS  TO  BE  SHARED  AND  REUSED.  GOING  DOWN  TO  THE 
DERIVATION  LEVEL  IS  NECESSARY  FOR  UNDERSTANDING  THE  DERIVATION  BUT 
ONE  STILL  NEEDS  A  STANDARD  FOR  THE  COMPLEX  DATA  ELEMENT,  ELSE  IN 
DATA  EXCHANGE,  ONE  WOULD  HAVE  TO  SEND  ALL  THE  ATOMIC  DATA  NEEDED 
FOR  THE  RECEIVER  TO  DERIVE  THE  COMPLEX  DATA  VALUE.] 
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Task  94-6:  draft  EW  Data  Set  Methodology:  involves  data  normalization,  metadata,  DE 
harmonization  (cross  model  concurrence),  DE  comparison  with  operational  DEs,  and  DE 
standardization  for  DDRS  submission. 


Mr.  Mike  Hopkins:  Data  Quality  Engineering  Tool  Project 

The  CENTCOM  DQE  process  applies  the  data  element  dictionary  constraints  and  rules  specified 
by  the  Database  Administrator  (DBA)  against  the  instance  data,  tagging  errors  and  sending 
formal  data  trouble  reports  back  to  the  data  providers  in  a  file  format  the  providers  are  familiar 
with  The  system  is  designed  to  be  used  by  any  organization's  DBA  desiring  to  check  data  in  a 
UNIX  environment  using  an  INGRES  DBMS.  The  fixed  length  source  files  can  be  unlimited  in 
number,  format,  and  content.  DQE  is  a  system  with  six  major  functional  areas:  (1)  Data 
Element  Dictionary;  (2)  Source  File  Processor;  (3)  Data  Quality  Validation;  (4)  Data  Trouble 
Reports  (DTR);  (5)  Query/Rule  Builder;  and  (6)  system  maintenance  functions. 


DQE  functionality  will  produce  better  data  by:  providing  problem  reporting  process,  improving 
database  VV&A  checks,  enhancing  data  administration,  tracking  data  element  sources  and 
models  and  providing  an  architecture  to  standardize  data  descriptions  and  data  elements.  DQb 
provides  an  automated  process  of  applying  business  rules  to  identify  data  problems  on  incoming 
data  by:  automated  comparisons,  rules  (operational,  technical  and  procedural),  math 
computations,  acceptable  range  and  domain  checks,  missing  data,  duplicate  keys,  ™litary 
dependency  tests,  and  statistical  tests.  An  interactive  editor  guides  the  user  through  the  DQb 
processes  and  the  rules  editor  interactively  allows  the  user  to  create  or  update  rales  (using  SQL 
statements),  verify  that  the  rule  elements  are  valid,  verify  SQL  syntax,  and  spell  check  the  rale. 
The  data  trouble  report  processor  does  error  display  and  validation  and  views  or  prints  the  data 
trouble  reports  as  well  as  tracking  them. 


The  portable  tool  will  be  completed  by  September  1995. 


Mr.  Jim  Santangelo:  Universal  Threat  System  for  Simulators 

The  UTSS  Repository  will  be  a  Sun/Database  server  that  will  have  inputs  from  intel  source  data, 
blue  source  data,  simulation  software,  descriptions  of  source  databases  and  simulations,  and 
standards.  Its  products  include  threat  data,  catalogs  (data  and  software  distributed  via  WWW  and 
floppy  disc),  standards  and  simulation  software.  Its  customers  are  simulators,  developers,  trainer 
procurements,  DIS  users  (e.g.,  STOW),  and  other  M&S  users.  The  UTSS  Repository  will  be 
accessed  via  user  workstations  on  a  LAN  via  a  GUI  and  import  and  export  software.  Repository 
tools  include  GUI  tools,  filter  programs  and  unclassified  WWW  access  to  a  catalog  for 
automated  ordering. 

The  data  requirements  are  being  developed  through  use  of  JDBE  reverse  engineering  Trrr. 
methodology.  The  process  is  to  take  the  physical  models  of  five  system  databases  (F-14D,  U  ID, 
UH-1N,  MODSAF,  and  Source)  and  normalize  these  into  logical  data  models  that  are  then 
integrated  into  an  SAI  model  that  is  the  initial  UTSS  database  logical  model.  Data  standards  will 
be  based  on  that  model  and  that  model  will  be  used  to  derive  the  UTSS  physical  database. 

NAWC  Indianapolis  will  be  the  initial  testbed  facility  for  UTSS  and  is  responsible  for  system 
integration,  database  design,  and  software  development.  It  is  being  assisted  in  data  requirements, 
modeling  and  standardization  by  JDBE  with  additional  contractor  and  government  support  or 
interface  requirements  analysis  and  specification  development,  real-time  simulation  software 
expertise,  and  simulator  Subject  Matter  Experts. 

Status:  they  have  completed  the  logical  data  models  for  ModSAF,  UTD,  F-14D,  UH-1N,  IECSS, 
and  AH-1W  but  these  are  awaiting  verification  from  developers.  They  are  beginning  to  model 
the  source  databases  and  to  integrate  the  data  models  into  a  global  threat  data  model  to  be  used 
for  UTSS  database  design.  The  NAWC  testbed  facility  has  three  builds  scheduled:  April,  June, 
and  September  and  appear  to  be  on  schedule.  They  are  working  with  DIA  to  begin  the  formal 

DIA  data  acquisition. 
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The  benefits  of  data  modeling  is  that  it:  (1)  identifies  standard  representations  for  threat  data 
within  M&S  applications  (can  be  used  for  future  developments);  (2)  aids  in  fidelity  assessment 
of  simulator  software;  (3)  aids  in  assessing  interoperability  of  models;  and  (4)  has  helped 
developers  and  maintainers  to  better  understand  their  data. 

Data  Modeling  Lessons  Learned:  (1)  documentation  of  simulator  databases  is  often  scarce,  of 
poor  quality,  non-existent,  out  of  date;  (2)  IDEF1X,  though  not  perfect,  can  be  used  to  model  a 
variety  of  data  implementations  (RDBMS  and  flat  files);  (3)  with  minimum  training  (1  hour) 
simulator  maintainers  and  developers  can  understand  enough  of  IDEF1X  to  review  data  models; 
and  (4)  the  most  effective  data  model  development  has  been  off-site  development  of  draft  models 
using  available  documentation  followed  by  an  on-site  visit. 

Issues  are  (1)  data  tagging  (source,  classification,  validity  and  dates);  (2)  multilevel  security 
(initial  plans  for  system  high  repository,  future  to  do  distribution  via  trusted  system,  have  not 
addressed  data  aggregation  issue);  and  (3)  availability  of  data  (some  data  (US/friendly)  is 
difficult  to  obtain,  simulators  often  use  "best  estimates." 

UTSS  also  has  a  very  active  Standards  Working  Group  (SWG)  consisting  of  Service,  DIA  and 
industry  participants.  They  have  developed  a  standard  architecture  build  process  that  will  go 
from  Strawman  document  to  Ironman  document  to  Goldman  document.  SWG  issues  include 
need  for  more  Army  and  Navy  funding,  need  to  interface  with  other  DMSO  projects  working  on 
standard  architectures,  and  need  to  prove  their  architecture  is  workable. 

Ms.  Susan  Solick:  W&A  of  Distributed  Simulations  Project 

This  project  used  the  IDEFO  process  to  review,  refine  and  expand  the  standard  DIS  VV&A 
process  model  approved  at  the  10th  Workshop  on  Standards  for  the  Interoperability  of 
Distributed  Simulations.  The  first  year  of  the  project  addressed  M&S  verification  and  the  second 
year  will  address  validation. 

Ms.  Solick  is  responsible  for  the  data  consistency  task  and  has  made  an  initial  pass  at 
decomposing  the  data  VV&C  portions  of  the  M&S  verification  process.  The  DRTWG  Data 
VV&C  Guideline  Subgroup  had  given  her  some  higher  level  inputs  via  the  co-chairs  (Mr.  Bob 
Hartling  and  Mr.  Mark  Ralston)  who  are  active  on  this  project  and  the  DIS  VV&A  effort.  The 
Data  VV&C  Subgroup  has  selected  Mr.  Jeff  Rothenberg  (who  is  developing  the  data  quality 
profile)  to  work  with  Ms.  Solick  on  the  data  VV&C  effort.  Since  the  completed  IDEFO  model 
specification  will  contain  approximately  60  activities  and  over  100  pages  of  written  activity 
procedures  and  ICOM  definitions,  Ms.  Solick's  effort  will  require  an  in-depth  review.  She 
invited  DRTWG  members  to  share  data  issues  with  her  at  the  Data  VV&A  Guidelines  Subgroup 
meeting. 

There  was  some  discussion  (as  before)  on  what  it  meant  to  be  compliant  and  compatible  with 
DIS.  What  is  required  in  compliance  testing  of  data,  for  example.  It  was  also  pointed  out  that 
the  OSD  acquisition  process  doesn't  allow  for  development  of  a  DIS  simulation  as  shown  in  Bob 
Lewis'  IDEFO  process  model.  The  problem  is  current  acquisition  policy  requires  deliverables  be 
declared  in  upfront  documentation. 

The  VV&A  project  interim  deliverables  include  a  methodology  handbook,  an  IDEF  model 
specification  for  VV&A  of  distributed  simulations,  and  a  compendium  of  high  resolution 
algorithms.  Future  activities  are  to:  further  decompose  the  data  portions  of  the  model;  reconcile 
compliance  testing  specification  with  1ST  compliance  test  suite;  test  the  process;  complete  the 
methodology  handbook;  begin  the  implementation  guide;  and  establish  second  year  funding  for 
V&A  portions  of  the  program. 


3.7  REPORTS  FROM  OTHER  GROUPS 

Mr.  Peter  Valentine:  Report  on  IEEE/CS/SESC IDEFIX  Standards  Working  Group 
1320.2 

The  philosophy  of  standards  is  that  a  standard  should  address  the  needs  of  its  users.  These  needs 
change  over  time  and  needs  of  individual  users  change  at  different  times.  Therefore,  a  standard 
must  address  a  range  of  needs,  supporting  both  historical  and  emerging  practices. 

The  objectives  of  WG  1320.2  are  to  develop  IEEE  (ANSI-level)  standards  for  IDEFIX  (syntax 
and  semantics  and  the  user  guide)  and  evolve  the  language  and  practice  standards  in  parallel  with 

the  needs  of  the  users. 

Currently,  the  WG  is  working  on  (1)  completing  the  annotation  of  the  IDEFIX  formalization  to 
make  it  more  accessible;  (2)  completing  specification  of  an  optional  constraint  language,  (3) 
revising  the  baseline  draft  to  accommodate  enhancements;  and  (4)  beginning  development  ot  a 

user  guide. 

•  The  need  for  a  metamodel  to  put  in  the  repository  to  be  able  to  interchange  data  models 
using  CDIF.  The  objective  is  to  get  from  many  versions  of  the  IDEFIX  language  to  a 
common  formal  version. 


That  the  rule  constraint  language  (RCL)  will  allow  one  to  state  data  derivations. 

That  the  IDEF  group  will  probably  be  merging  with  the  Business  Process  Re-engineering 
(BPR)  group  that  used  IDEFO  since  about  90%  of  the  IDEFIX  WG  people  are  IDEFO 
practitioners. 


•  IDEF3  will  add  state  to  IDEFO  modeling  and  IDEF4  is  addressing  object-oriented 
modeling.  There  is  no  logical  connection  or  progression  among  the  IDEFs. 

A  question  was  asked  about  their  addressing  complex  data  and  the  answer  was  that  the  WG  focus 
is  more  on  business  applications  than  scientific  and  technical  data.  However  areas  relevant  to 
complex  data  that  are  being  addressed  are  providing  object  identities;  expanding  the  RCL  to 
describe  methods;  and  looking  at  abstract  data  types  (i.e.,  simple  domains).  Structural  complexity 
could  be  handled  through  ADTs. 


Ft.  Huachuca  will  be  hosting  the  next  WG  1320.2  meeting  on  February  24-26. 


Ms.  Rebecca  Wade:  Department  of  the  Navy  Data  Administration 

Ms.  Wade  is  the  Navy  Component  Data  Administrator  (CDAd)  from  the  Naval  Infonnation 
Systems  Management  Center  (NISMC).  They  are  currently  in  the  startup  phase  of  DA  (before 
1988-1989  there  was  no  enterprise-wide  view  in  DON).  This  includes  concept  definition 
(understanding),  developing  terms  of  reference  and  roles  and  responsibilities,  training,  putting 
the  processes  in  place  (mainly  for  data  modeling  and  DE  standards),  finding  the  resources  an 
defining  the  issues.  The  DoD  policies  and  procedures  stop  at  the  CDAd  door,  there  is  no  real 
definition  of  how  the  Component  should  carry  them  out. 
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In  the  data  modeling  area:  they  are  integrating  data  models  and  mapping  names  to  the  DDRS 
data  elements  since  most  of  DON  data  elements  belong  to  entities  that  are  already  approved. 

They  are  using  the  DON  data  model  to  support  their  activities,  mainly  as  a  holding  place  for  DE 
development  and  a  place  for  issues.  They  are  making  the  DoD  Data  Model  widely  available 
throughout  the  Navy.  Navy  data  elements  that  are  approved  can  be  downloaded  through 
Technet.  There  are  forms  for  becoming  a  Technet  user  and  for  becoming  a  DDRS  user.  They  set 
up  meetings  for  modeling  Navy  information  and  are  trying  to  track  the  modeling  groups.  They 
use  the  PCAT  tool  for  accessing  the  DDRS  (the  PCAT  tool  is  available  for  downloading  through 
the  MSRR).  The  Enterprise  Bulletin  Board  at  DISA  is  also  available  for  use. 


To  understand  your  data  elements  you  need  to  understand  your  policies,  be  able  to  access  data 
element  metadata,  and  relate  all  to  a  data  model.  This  is  what  one  does  in  an  interim  repository. 
They  need  data  elements  within  a  context  to  support  a  particular  functional  area  or  system.  They 
need  to  develop  an  information  map,  baseline  Navy  requirements,  and  priorities  to  enable  the 
development  of  a  transition  strategy  to  move  to  standard  data  elements.  There  also  has  to  be 
continued  support  of  Navy  legacy  systems. 

They  have  over  1,000  data  elements  in  the  SDE  approval  process  and  if  GCCS  lives  up  to  its  DE 
commitments  there  could  be  many  more  standard  data  elements.  She  is  not  sure  if  the  Navy  has 
determined  all  of  its  requirements  for  a  dictionary  and  it  may  turn  out  they  will  need  a  Navy¬ 
wide  data  dictionary.  The  Navy  needs  to  include  DA  in  its  other  policies. 

There  are  resource  issues  because  it  is  difficult  to  get  institutional  support  for  DA.  Issues  include 
future  requirements  and  validity  and  credibility.  There  needs  to  be  a  balance  between  ^ 
requirements  so  that  a  "to  be"  approach  can  be  mapped  back  to  transition  from  the  as  is. 

Their  overall  status  is:  they  are  in  the  startup  phase  with  initial  operating  capability  and  have 
begun  implementation. 
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3.8  REPORT  ON  THE  M&S  COMMUNITY  DIRECTORIES 
Ms.  Peggy  Gravitz:  Report  on  the  M&S  Community  Directories 

The  M&S  and  Database  directories  have  had  many  names.  At  a  recent  meeting  at  Ft.  Huachuca 
(Feb.  13-14)  for  the  purpose  of  integrating  the  Authoritative  Data  Sources  data  model  into  the 
existing  M&S  and  Database  Data  Model  and  extending  the  combined  model  to  accommodate 
relevant  DMA  Catalog  metamodel  entities  and  data  elements  it  was  agreed  to  by  those  present  to 
call  the  directories  the  "M&S  Community  Directories."  However,  at  the  time  this  brief  was 
given,  the  data  models  had  not  been  integrated  and  Ms.  Gravitz  was  only  addressing  the  M&S 
and  Database  directories. 

The  purpose  of  the  brief  was  to  describe  a  phased  approach  for  developing  the  M&S  Community 
Directories  for  the  MSRR.  This  is  a  DMSO  FY95  investment  to  SSDC  with  their  COLSA 
contractor  carrying  out  the  effort.  COLSA  previously  developed  the  integrated  M&S  and 
Database  Data  Model  with  DMSO  support. 

Phase  I:  automate  current  DMSO  M&S  directories  with  a  WWW  interface  and  add  the 

Database  Directory. 

Phase  II:  develop  a  standard  WWW  hypertext  document  format  based  on  the  M&S 

Community  Directories  logical  data  model  and  provide  WWW  interface 
enhancements  for  data  entry/browsing/retrieval. 

Phase  III  J:  assist  each  Proponent  M&S  directory  custodian,  at  their  site,  in  the  installation 
of  their  M&S  directory  links  to  the  MSRR  through  the  WWW. 

Phase  IV  J:  develop  a  physical  M&S  Community  Directories  database  implementation 
based  on  the  M&S  Community  Directories  logical  data  model  with  a  WWW 
interface. 
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3.9  REPORTS  FROM  DISA/JIEO 
Mr.  Peter  Pasek:  DoD  Repository 

Mr.  Pasek  joined  DISA/JIEO  recently  as  part  of  the  transfer  of  the  Army  data  standards  people 
(Jim  Glymph's  group)  to  DISA.  Current  DISA  tools  are  the  Defense  Data  Repository  System 
(DDRS),  the  DIST,  and  the  interim  repository.  The  future  potential  repository  solution  for  DoD 
will  be  based  on  COTS  software.  Mr.  Pasek  said  that  many  years  ago  the  Army  had  Lawrence 
Livermore  Labs  define  a  data  encyclopedia  architecture  for  them  and  then  decided  it  was  overkill 
and  went  on  to  build  the  Army  Data  Dictionary  system.  The  Army  Corps  of  Engineers 
developed  the  ADD  which  is  the  "grandfather"  of  the  DDRS.  Today  we  have  DoD  8320,  agreed 
on  IDEF  methodology,  database  management  maturity,  and  IRDS  -  all  things  that  were  not 
available  ten  years  ago.  These  can  all  help  define  the  future  repository  product. 

He  defined  a  repository  as:  a  specialized  application  that  provides  for  shared  storage  and 
common  access  for  data  and  objects  required  to  support  enterprise  information  systems  and 
database  development  and  reengineering. 

They  are  building  a  Repository  Information  Model  (RIM)  made  up  of  schemas,  etc.  of  other 
tools.  This  was  the  result  of  the  DIRS  project.  The  objective  is  to  get  the  DDRS  database 
schema,  IDEF  repository,  DIST  tools,  and  the  ADD  all  defined  in  a  global  schema.  RIM  will  be 
used  as  the  basis  for  selection  of  the  DDR  COTS  tools  but  all  the  other  systems  will  not  go  away. 
Through  system  integration,  the  new  repository  will  be  able  to  access  all  the  older  tools.  The 
DDRS  may  still  be  used  for  entering  data  elements. 

The  DDR  project  has  been  gathering  many  requirements.  The  DDR  steering  committee  direction 
is  more  focused  on  getting  the  new  requirements  into  the  new  repository  than  on  fixing  the 
shortcomings  of  the  DDRS  in  the  new  repository.  They  are  currently  involved  in  acquisition  and 
by  February  will  have  a  statement  of  work  and  will  acquire  the  DDR  through  a  private  RFP 
process  with  Logicon  as  the  integrating  contractor.  They  expect  a  contract  award  by  June  since 
this  is  a  private  RFP  not  subject  to  the  GSA.  They  expect  to  have  an  operational  system  by  30 
September  that  will  be  a  COTS  tool  with  limited  capability.  Carl  Palmer  is  directing  the 
resources  for  DDR  development. 

The  first  phase  of  the  DDR  will  be  to  serve  data  administration  users,  data  modelers,  data 
standards  people  and  software  developers.  The  DDR  will  be  an  evolutionary  product,  it  will  be 
termed  a  prototype.  It  will  really  be  performing  as  a  frontend  integrator  to  existing  tools.  It  will 
be  on  the  same  box  as  the  DRS  but  people  will  need  to  buy  a  workstation  to  use  it  since  it  is  a 
client/server  architecture  and  the  client  software  will  reside  on  a  PC.  DoD  will  have  an  option  to 
buy  six  server  products.  The  requirements  selection  is  being  made  in  view  of  what  can  be  done 
in  one  year  for  under  $1,000,000. 

He  gave  us  one  page  of  potential  repository  objectives  which  include  reuse/reshare  models  and 
metadata  information  between  systems,  databases,  and  systems  development  tools;  document 
current  system  process,  and  data  environment;  identify  data  location,  usage  and  access;  map 
current  data,  process  and  system  information  to  models;  facilitate  effective  technical 
communication  of  models  and  metadata  between  organizations  and  the  business;  etc.  He  also 
gave  us  a  one  page  list  of  potential  repository  requirements  that  are  rather  general  and  not 
unexpected. 

He  showed  a  final  viewgraph  of  the  expected  solution  which  will  support  multiple  languages; 
multiple  data  dictionaries;  multiple  DBMS  schemas,  mappings,  DDLs,  tables;  multiple  methods, 
techniques  and  standards;  multiple  development  tools  using  CASE  metadata  exchange;  etc. 
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Ms.  Miranda  Stern:  Data  Quality  and  Security 

The  focus  areas  in  data  quality  and  security  are:  (1)  data  quality  in  AIS  migration;  (2)  tools;  (3) 
baseline  quality  assessment  (using  the  Automated  Resource  Management  System  (ARMS)  and 
Solid  Waste  Automated  Repository  (SWAR)  as  pilot  studies);  (4)  data  quality  and  data  security 
guidelines;  and  (5)  guidelines  for  metrics  (QA).  The  DA  goal  4  establishes  the  data  quality 
management  process  "...ensure  that  DoD  operations  and  decision  making  are  supported  with  data 
meeting  needs  of  availability,  accuracy,  timeliness,  integrity,  and  need-to-know  requirements." 

The  DoD  definition  of  data  quality  is:  "The  degree  of  compliance  between  an  organization  s  data 
environment  and  its  "business  rules."  (The  DRTWG  attendees  seemed  to  have  a  problem  with 
this  definition.)  She  showed  the  data  quality  in  AIS  migration  as  first  establishing  quality  and 
cost  baselines  in  legacy  systems,  then  improving  the  quality  in  transitioning  to  migration  systems 
through  selection  of  the  best  sources,  and  finally  building  data  quality  into  the  target  systems. 

She  gave  us  a  list  of  data  quality  tools  and  showed  interest  in  the  new  DQE  tool  developed  at 
CENTCOM. 

There  was  a  separate  short  brief  on  data  quality  metrics  that  addressed  DoD  data  systems  in 
general:  the  percentage  and  number  of  DoD  standard  data  elements  in  each  migration/target 
system;  percentage  of  DoD  migration/target  systems  using  shared  databases  and  DoD  standard 
data  elements;  percentage  of  user  data  that  meets  established  data  quality  standards;  etc.  They 
are  using  selected  data  administration  metrics  for  doing  evaluation  and  assessments.  The 
questions  asked  are  very  broad,  such  as  are  common  databases  used  when  service-unique 
databases  are  not  required;  does  a  database  application  use  relational  theory;  was  a  database 
designed  using  standard  data  modeling  techniques;  was  the  database  based  on  the  DoD  data 
model;  etc. 


Ms.  Angela  Booker:  GCCS  Data  Standardization  _  A  , 

The  C3  FDAd  is  Ms.  Deborah  Castleman,  who  is  the  DASD(C3);  Ms.  Booker  is  the  C3  FDAd 
Alternate  POC.  The  C3  FDAd  mission:  achieve  a  fully  interoperable  C3  environment  through 
effective  data  standards  coordination  and  program  development,  including  data  element  and  data 
models  for  C3  projects,  programs,  and  migration  systems. 


The  GCCS  migration  systems/databases  include:  GSORTS,  DART,  LOGSAFE,  FAPES, 
JFAST,  OSS,  ATO/ACO,  and  JOPES.  These  have  been  reengineered  to  identify  their  data 
elements  and  have  undergone  data  modeling  to  show  overlaps  in  data  elements.  Efforts  in  data 
element  production  have  included  consolidating  GCCS  data  requirements  from  Component 
systems;  performing  collaborative  data  modeling;  and  extensions  to  the  C2  Core  Model  which 
are  ongoing  and  result  from  C3  functional  area  data  model  development  and  functional  process 
improvement  projects. 


For  the  collaborative  modeling  process,  they:  develop  and  review  read-ahead  packages, 
monitor/support  the  sessions,  and  prepare  the  proposal  package.  They  have  36  collaborative 
clusters  planned.  The  one  on  GEOLOCATION  (that  M&S  took  part  in)  started  in  September 
1994  Concurrent  efforts  are  going  on  in  all  the  collaborative  modeling  subject  areas. 
ORGANIZATION,  MATERIEL,  FACILITY,  TRANSPORTATION,  OPERATIONS,  PERSON, 
PLAN  and  INSTALLATION.  On  the  GEOLOCATION  collaboration,  they  developed  a  C2 
model  for  generic  location  instead  of  using  a  model  from  another  community.  Some  people  felt 
that  the  right  people  weren't  at  the  session,  and  some  felt  that  the  way  of  doing  it  wasn  t  right. 

The  process  was  to  develop  the  TO-BE  model  and  then  use  existing  systems  to  validate  it  in 
order  to  discover  data  to  carry  forward. 


Functional  process  improvement  has  been  carried  out  by  SOCOM  and  others  with  CIM  central 
funding  They  get  the  To-BE  pictures  and  then  merge  these  into  a  C3  data  model.  They  are  also 
looking  at  the  Defense  Message  System  (DMS)  because  they  know  that  message  data  is 
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important.  TADILS  and  USMTF  (sister  divisions  to  her  division)  are  moving  their  message  data 
elements  into  data  standards.  They  are  beginning  to  map  this  data  to  the  C3  Core  Data  Model. 

JOPES  data  has  been  submitted  for  standardization  using  the  data  elements  in  the  1993  data 
model.  JOPES  data  bypassed  the  DA  process  and  has  been  rejected  by  two  FDAds 

The  JTF  ATD  (John  Schill/ARPA)  (architecture  by  Rick  Hayes-Roth)  is  managed  by  Howard 
Frank  (ARPA)  who  is  interested  in  data  modeling  as  part  of  the  LEE  GCCS  effort.  GCCS  has 
reengineered  the  migrating  systems  and  mapped  the  data  elements  back  to  the  C2  Core  Data 
Model.  They  will  use  standard  data  elements  in  the  GCCS  Version  3. 

C3  data  element  status  from  the  C2  Core  Data  Model,  Version  2  of  GCCS,  February  7, 1994: 

Prime  Words  Data  Elements _ 


Candidate 

Standard 


20 

106 


89 

289 
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3.10  ACTION  ITEMS 


1  Iris  Kameny:  Form  DRTWG  small  group  to  address  STOW  97  fast  data  build  (96  hours 
in  crisis)  requirement. 

2.  Iris  Kameny:  Get  Joint  Warfare  Simulation  Object  Library  documents  for  August  and 
March.  Charles  Herring  has  been  active  on  this  project  and  will  be  moving  to  DMSO  and 
will  be  the  one  to  bring  commonality  to  environmental  data  standards. 
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4.1  AGENDA 

FEBRUARY  8,  1995  AT  IDA 

1300-  1315  Introduction,  review  of  task  proposals,  status  of  DMSO  approval/funding:  Mr. 
Mark  Ralston  and  Dr.  Chien  Huo 

1315  -  1345  Task  1  plans:  Lt  Col  Dennis  Lester 

1345  -  1415  Task  3  plans:  Mr.  Mark  Ralston 

1415-  1445  Report  on  VV&A  of  DIS  efforts,  requirements  for  incorporation  of  results  into 
Task  2:  Ms.  Susan  Solick 

1445  -  1500  Break 

1500-  1 530  IDEF0  briefing  from  contractor.  (Contractor  selected  by  DMSO  to  support  IDEF0 
modeling  in  Tasks  1  and  3  presents  overview  of  IDEF0  and  talks  about 
requirements  from  participants.) 

1530-  1630  Brief  overview  from  each  case  study  organization  representative  on  the  process 
that  they  will  model  for  Tasks  1  and  3.  Q&A  with  IDEF0  contractor  on  the 
modeling  process.  (Need  to  make  sure  that  as  many  case  study  organization  reps 
as  possible  will  attend.) 

1630  -  1700  Preliminary  schedule  discussions,  Q&A  with  task  leaders:  Mr.  Mark  Ralston  and 
Lt  Col  Dennis  Lester 


DATA  W&C  GUIDELINES  SUBGROUP  MEETING  AT  IDA 
WEDNESDAY,  FEBRUARY  8,  1995 


4.2  FEBRUARY  8,  1995  ATTENDEE  IJST  (Cont’cL) 
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4.3  MAIN  OBJECTIVES  OF  MEETING 

The  objectives  of  the  meeting  were  (1)  to  review  current  plans  on  how  tasks  1  and  3  would  be 
performed  including  the  schedule;  (2)  making  everyone  familiar  with  the  case  study 
organizations  and  what  processes  they  are  likely  to  model  and  issues  they  face;  (3)  having  JDBE 
facilitator  describe  how  the  IDEFO  modeling  would  be  supported;  and  (4)  arranging  for  the  initial 
kickoff  meeting. 
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4.4  MEETING  NOTES 

Dr.  ChienHuo:  Tasking  and  Funding 

Dr.  Chien  Huo  described  how  he  wanted  to  handle  the  tasking  and  funding.  He  discussed 
milestones  that  need  to  be  met  to  be  compatible  with  the  Defense  M&S  Master  Plan.  Each  case 
study  leader  needs  to  tell  Chien  his  organization's  financial  person  (name,  phone,  fax,  address) 
and  use  of  funding  as  to  whether  it  is  to  be  spent  by  government  (reimbursable)  or  to  go  to  a 
contractor  (direct  cite).  The  task  leaders  have  the  responsibility  to  check  on  this  paperwork  and 
let  him  know  if  there  are  any  problems. 

Lt  Col  Denny  Lester:  Tasklnon-DIS  User  Data  VY&C 

Lt  Col  Denny  Lester  presented  the  Task  1  effort:  to  develop  guidelines  for  non-DIS  user  data 
VV&C.  The  approach  (same  for  Task  3)  was  to  divide  the  task  into  four  subtasks: 

1.  Develop  study  plan,  do  literature  search 

2.  Provide  IDEFO  training  and  tools  and  develop  IDEFO  VV&C  process  model  for  each  case 
study 

3.  Review,  compare  and  integrate  process  models  to  develop  generic  IDEFO  Model(s) 

4.  Document  methodology  and  criteria,  develop  recommendations  on  IDEFO  VV&C 
process  and  write  study  report 

Four  out  of  five  case  study  leaders  and  possible  M&S  have  been  identified  for  Task  1: 

USAF  —  Lt  Col  Denny  Lester,  TACCSF  (TACCSF) 

USA  —  Mr.  Howard  Haeker,  TRAC  (JANUS) 

Navy  —  Mr.  Jerry  Hoffman,  SPAWAR,  (ITEM,  campaign  level  model) 

JCS  _  ? 

OSD  —  Mr.  Eric  Keck,  JADS-JT&E,  (JADS) 

Task  1  will  run  from  March  95  to  end  of  March  96.  A  study  plan  with  detailed  schedule  will  be 
delivered  by  the  end  of  March  95.  Subtask  2  (individual  case  studies)  will  begin  on  April  1  and 
be  completed  by  September  1, 1995.  Bulk  of  the  effort  for  Subtask  3  will  be  completed  after 
September  1,  when  all  the  case  studies  will  have  been  completed. 

Denny  Lester  said  they  would  use  IDEFO  for  process  modeling  of  the  organization's  VV&C 
process  and  then  use  IDEF1X  and/or  an  object-oriented  modeling  technique  for  the  actual  data 
modeling  of  the  M&S  data.  [IRIS’  VIEW  IS  THAT  THE  DATA  MODELING  IS  MUCH 
MORE  THAN  WHAT  WE  NEED.  WE  ARE  ONLY  DOING  PROCESS  MODELING  TO 
BETTER  DETERMINE  GENERIC  VV&C  PROCESSES  APPLIED  TO  INSTANCE  DATA. 
THIS  DOES  NOT  REQUIRE  DATA  MODELING  AT  THIS  TIME.  HOWEVER,  CARRYING 
THE  VV&C  PROCESS  TO  A  DETAILED  ENOUGH  LEVEL  COULD  PRODUCE  DATA 
FLOWS  OF  METADATA  DESCRIBING  THE  DATA  QUALITY.  I  BELIEVE  THIS  WOULD 
REQUIRE  MUCH  MORE  EFFORT  THAN  WE  CAN  AFFORD  FOR  NOW.  PERHAPS 
MORE  DISCUSSION  IS  NEEDED  ON  THIS  TOPIC.] 

Denny  said  that  we  need  to  discuss  the  coordination  process  since  OSD  has  formalities  about 
reviews  and  timelines.  He  foresees  there  may  be  problems  getting  OSD  and  JCS  to  participate  in 
a  timely  fashion. 

He  also  suggested  that  in  subtask  3,  when  we  are  developing  generic  models,  we  may  want  to 
include  people  from  the  M&S  organizations  to  prevent  an  AS-IS  rice  bowl  process  from 
overpowering  a  better  TO-BE  process. 
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Denny  Lester’s  e-mail  notes  contained  these  issues  and  concerns. 

Issues  I 

1.  Determine  the  relationship  between  IDEFO,  IDEF1X,  and  Object-Oriented  data 
methodologies. 

2  Can  a  cost  analysis  be  performed  as  part  of  the  tasks  to  determine  national  funding 
required  to  do  data  VV&C?  [IN  THE  DISCUSSION  DENNY  OFFERED  THAT  BOB 
LEWIS  HAS  LOOKED  AT  50  CASES  FOR  VV&A  AND  CAN  USE  THESE  TO 
PREDICT  WHAT  IT  MIGHT  TAKE  TO  DO  VV&A.  WOULD  IT  HELP  TO  TRY  TO 
ESTIMATE  THIS  WHEN  DOING  THE  CASE  STUDIES?] 

3.  Can  non-combat  models  be  addressed  in  tasks? 

4.  Can  the  case  studies  include  models  at  all  levels  in  the  modeling  and  simulation  hierarchy 
(i.e.,  engineering,  engagement,  operational/mission,  and  campaign)? 

5.  How  can  the  case  studies/tasks  be  integrated?  Can  an  end-to-end  case  study  be 
performed  (i.e.,  Task  3  feeding  Task  1  feeding  Task  2)? 

6.  Determine  how  RAND's  Quality  Program  may  be  tied  into  these  tasks. 

7.  Determine  who  should  be  invited  to  task  working  group  meetings,  how  often  should  joint 
task  meetings  be  held,  and  who  should  accompany  JDBE  representatives  to  site  surveys 
(if  necessary). 

Concerns: 

1.  JDBE  appears  to  be  better  versed  in  IDEF1X  than  IDEFO.  Do  we  need  to  invite  anybody 
else  (e.g.,  BDM  or  COLS  A)  to  augment  JDBE. 

2.  Over-reliance  on  JDBE  to  integrate  process  models  from  case  studies  within  the  tasks 
without  proper  supervision. 

3.  Making  sure  we  can  describe  the  process  models  for  data  VV&C  in  terms  which  can  be 
understood  by  a  diverse  community,  e.g.,  data  experts,  modeling  and  simulation  users  and 
sponsors,  educators,  etc). 

Mark  Ralston:  Task  3  Data  Producer  W&C 

Task  3  subtask  descriptions  are  the  same  as  the  task  1  subtask  descriptions. 

Mark  identified  the  five  task  3  organizations  and  POCs: 

—  DMA,  Dave  Danko,  geo-physical  data  collection 

—  DIA,  Richard  Bernstein,  intelligence  data  collection 

—  US  Army  OPTEC,  Kerry  Wyant,  operational  test  data  collection 

—  Naval  Oceanographic  Office,  Eleanor  Schroeder,  oceanographic  data  collection 

—  National  Air  Intelligence  Center,  Ray  Pershing,  aircraft  technical  data  collection 

Task  3  milestones:  are  similar  to  the  Task  1  milestones 

Analysis  Issues: 

1.  Can  we  define  a  generic  W&C  process  for  DoD  data  producing  organizations? 

2.  What  are  the  similarities  and  differences  in  the  processes  used  by  DoD  data  producers  to 
perform  VV&C? 

3.  What  tools  and  techniques  should  be  used  for  data  W&C  by  DoD  data  producers? 

4.  What  costs  are  incurred  by  the  use  of  data  VV&C  techniques  at  DoD  data  producing 
organizations? 

5.  What  are  the  benefits/savings  accrued  by  the  use  of  data  VV&C  techniques  at  DoD  data 
producing  organizations? 

Planning  Issues: 

—  Selection  of  processes  within  case  study  organization 

—  Development  of  generic  process  model/models 

—  Feasibility  of  obtaining  cost/benefit  data 
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—  Coordination  of  tasks  1  and  3,  integration  of  results 

—  Planning  meeting  schedule 

—  IDEFO  modeling  schedules,  SME  availability,  training 

Mark  Ralston  laid  out  the  study  report: 

—  Consolidated  with  task  1  and  2  reports 

—  Identifies  generic  processes 

—  Identifies  methods,  tools,  and  techniques 

—  Formulates  VV&C  guidelines 

—  Published  as  a  DoD  instruction 

Susan  Solick:  Task  2  DIS  User  Data  W&C 

Susan  went  over  the  DIS  Exercise  Process  Model  showing  VVA/C  and  detailed  charts  on  how 
she  has  expanded  on  the  data  VV&C  at  appropriate  places  in  the  process.  [FROM  IRIS:  WE 
REALLY  NEED  TO  FORM  A  SMALL  GROUP  TO  EXAMINE  THESE  MORE  CLOSELY 
AND  GET  BACK  TO  HER]> 

The  current  status  for  DIS  data  VV&C: 

—  VV&C  model  decomposition  is  complete 

—  Final  draft  of  manager's  guide  is  ready  for  distribution  by  March  1 

—  First  draft  of  implementation  guide  is  in  progress 

—  IDEFO  model  and  specs  of  VV&A  process:  verification  portion  will  be  ready  by  April  1 
(validation  is  objective  of  next  phase) 

—  Continued  coordination  with  other  groups 

Susan  said  that  there  will  be  a  hole  in  Task  2  with  respect  to  VV&C  related  to  M&S  validation 
since  that  is  their  project's  phase  2  effort  and  hasn’t  begun  yet.  However,  they  are  beginning  to 
agree  on  the  terms  of  compliance  and  compatibility  with  DIS.  There  were  questions  as  to  what  is 
meant  by  a  data  set  being  compliant/compatible  with  DIS. 

Susan  said  there  will  be  a  DIS  data  issues  subgroup  at  the  next  DIS  WS  to  discuss  VV&C- 
W&A  interactions;  repository  relationships;  W&C  role;  and  SIMWORLD  and  MSRR. 

Gary  Lambert  (JDBE):  Gave  an  overview  of  IDEFO. 

TASK  1  CASE  STUDIES  WERE  BRIEFED. 

Rick  Munro  (Navy/ITEM):  Issues  included  use  of  service  accepted  M&S  products;  how  M&S 
are  used  varies;  and  the  data  sources  used  in  a  model  may  vary  with  the  different  purposes  of  use. 

Cathy  Corley  (USA/TRAC/TADS):  TADS  supplies  data  to  VIC,  EAGLE,  JANUS, 
CASFORUM,  battle  labs.  The  case  study  will  have  to  focus  on  one  of  these.  They  support  the 
need  for  a  cost/benefit  analysis  to  understand  how  much  data  VV&C  is  worth  doing. 

Tony  Brozena  (Air  Force):  Discussion  of  tying  choice  of  model/application  to  need  for 
producer  data  such  as  DIA  so  that  we  can  follow  thread  of  producer  data  VV &C  to  use  of  the 
VV&Ced  data  in  non-DIS  user  data  W&C. 

TASK  3  CASE  STUDIES  WERE  BRIEFED. 

Kerry  Wyant  (Army  OPTEC):  Their  data  is  not  used  by  others  now  but  they  are  interested  in 
their  To-BE  data  and  what  kinds  of  quality  testing  that  will  require.  What  quality  assurances 
have  to  be  done  to  make  their  data  reusable  by  others? 

Dave  Danko  (DMA):  They  have  300  product  lines,  each  with  a  different  W&C  process.  On 
the  other  hand,  he  expected  that  there  might  be  a  similarity  between  DMA  data  VV&C  and  the 
Navy  oceanography  data  VV&C. 
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Eleanor  Schroeder  (Navy):  They  have  the  same  problems  as  DMA.  Different  products  have 
different  VV&C  processes. 

Richard  Bernstein  (DIA):  They  have  order  of  battle  and  facilities  data.  Data  VV&C  is  done  by 
analyst  as  the  data  is  put  into  the  database.  Substantive  VV&C  stops  with  the  analyst.  Some 
problems  with  their  databases  is  that  they  need  metadata  about  the  database.  Questions  were 
asked  about  some  of  their  unusual  data  structures:  their  data  formats  are  structured  to  be  able  to 
describe  many  different  facilities  and  OBs. 

Ray  Persing  (AF/NAIC):  They  address  aircraft  design  and  have  aircraft  performance  data  for 
all  the  aircraft  in  the  world.  Their  data  is  documented  but  they  perform  informal  VV&C. 
Sometimes  for  a  new  aircraft,  they  have  to  validate  data  against  best  existing  aircraft/systems.  A 
concern  they  have  is  with  where  to  stop  the  VV&C  process  (how  much  is  enough?) 
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4.5  ACTION  ITEMS 

1.  Conduct  kickoff  meeting  in  Albuquerque  on  February  27-28  for:  Task  1  and  Task  3 
leaders,  supporting  organizations,  case  study  representatives,  and  JDBE  DDEFO 
facilitators 

2.  Task  1&3  leaders  will  provide  update  task  descriptions  as  soon  as  possible  to  Chien  Huo 
and  Iris  Kameny  using  new  template  provided  by  Iris  Kameny. 

3.  The  Task  1  leader  (Denny  Lester)  will  provide  addresses  for  his  case  study  budget  POCs. 

4.  Add  to  current  Data  W&C  Task  Description:  delivery  of  a  draft  final  report  by  3 1  Dec 
95  and  requirement  for  intra-service/department  coordination. 

5.  Task  1  and  task  2  leaders  are  to  confirm  that  all  case  study  participants  have  received 
funds  by  27  Feb.  Exception  is  that  Task  1  will  not  have  commitment  from  JCS  until  after 
the  kick-off  meeting  in  Albuquerque 

Denny  Lestert  Suggested  Additional  Actional  in  his  E-mail  Notes 

1.  Determine  site  preparation  requirements  prior  to  interviews  being  conducted  by  JDBE  at 
each  case  study  location. 

2.  Build  a  library  of  appropriate  data  VV&C  references. 

3.  Develop  a  PERT  diagram  of  Tasks  1  and  3  and  stop-light  charts  to  monitor  milestone 
completion. 

4.  Develop  a  list  of  Data  VV&C  POCs  and  subject  matter  experts. 

5.  Investigate  the  possibility  of  starting  an  e-mail  reflector  system  for  the  folks  supporting 
the  Data  VV&C  tasks. 
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5.1  AGENDA 

THURSDAY,  FEBRUARY  9, 1995 

0800  -  0830  Objectives  of  VV&A  TWG  and  Progress:  Dr.  Pat  Sanders 

0830  -  0900  Objectives  of  Data  VV&C  Task  Force  and  Progress:  Ms.  Iris  Kameny 

0900  -  1000  Discussion  of  Common  Topics  and  Interfacing  Arrangements:  Led  by  Dr.  Pat 
Sanders  and  Ms.  Iris  Kameny 


NOTES  FROM  JOINT  MEETING  OF  DMSO  W&A  TWG  AND 
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5.3.  MAIN  OBJECTIVE  OF  MEETING 

This  was  the  first  joint  meeting  of  the  DMSO  VV&A  TWG  and  the  DMSO  DRTWG  Data 
VV&C  Task  Force.  The  objective  was  to  familiarize  each  group  with  the  objectives  and 
accomplishments  of  the  other  group  so  that  there  can  be  better  coordination  and  cooperation  in 
the  future.  In  the  past,  this  has  been  done  informally  mainly  by  a  few  people  talking  outside  of 
scheduled  meetings. 
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5.4  MEETING  NOTES 

It  was  announced  that  Priscilla  Vanderpool  is  the  DMSO  technical  support  representative  for 
VV&A.  The  DMSO  representative  for  the  DRTWG  is  Dr.  Chien  Huo. 

DR.  PAT  SANDERS  DISCUSSED  THE  OBJECTIVES  AND  PROGRESS  OF  THE  DMSO 
VV&A  TWG 

The  VV&A  TWG  wrote  the  M&S  VV&A  section  of  the  Defense  Modeling  and  Simulation 
Master  Plan  (Sub-objective  5-2,  see  Appendix  A  attached).  The  data  VV&C  TF  contributed  the 
VV&C  part  of  that  sub-objective.  The  VV&A  TWG  has  also  been  working  on  the  investment 
plan  to  support  the  master  plan  objectives,  staff  development  for  VV&A  practitioners,  and 
writing  VV&A  documents. 

The  main  issue  with  VV&A  is  affordability.  How  much  V&V  is  enough  for  a  given  purpose, 
how  much  can  one  afford,  what  does  what  is  affordable  buy  you,  etc. 

The  DoD  instruction  for  VV&A  is  out  for  review  and  makes  V&V  an  integral  part  of  model 
development.  The  V&V  of  a  model  is  to  be  documented  in  an  accreditation  report  that  will  be 
available  to  users  interested  in  reusing  the  model.  The  VV&A  TWG  has  addressed  distributed 
and  joint  simulations  as  well  as  single  Component  M&S  by  providing  flexibility  for  an 
individual  Component  to  address  the  V&V  of  their  own  models  but  requiring  some  form  of 
common  studies  for  a  joint  model.  The  VV&A  process  includes  the  VV&C  of  data  used  by  the 
M&S. 

M&S  VV&A /C  will  become  more  important  as  M&S  results  are  used  more  and  more  to  feed 
into  the  decisionmaking  process.  Dr.  Sanders  expects  the  Defense  Science  Board  (and  others) 
will  be  requiring  increased  assurances  that  an  M&S  and  its  data  have  been  VV A/Ced  when 
recommendations  are  made  to  decisionmakers  that  are  based  or  backed  up  with  M&S  results. 

How  do  we  need  to  go  about  accrediting  M&S?  We  need  some  draft  procedures  to  try  out  on 
prototypes  before  releasing  procedures  to  the  community.  The  currently  planned  pilot  studies  on 
complex  models  include  an  ALSP  confederation  and  DIS. 

A  question  was  asked  about  how  to  do  VV&A  on  a  M&S  that  will  be  used  to  affect  the 
acquisition  of  a  weapon  system  that  doesn't  exist.  A  relevant  answer  may  have  been  offered  on 
the  previous  day  at  the  Data  VV&C  Guidelines  Subgroup  meeting  when  Ray  Persing  (National 
Air  Intelligence  Center)  told  us  how  they  model  information  about  a  new  foreign  aircraft  by 
filling  in  missing  information  based  on  the  new  aircraft's  similarity  to  existing  aircraft  for  which 
they  have  more  complete  information. 

The  VV&A  TWG  is  focusing  on  what  degree  of  validity  is  needed  for  a  M&S  based  on  its 
purpose.  They  intend  to  work  with  M&S  VV&A  histories.  The  credibility  of  a  model  will  be 
built  over  time  based  on  its  VV&A  history  and  the  credibility  of  its  past  results  (even  if  these 
were  to  answer  slightly  different  questions).  An  issue  is  how  to  document  this  historical 
information  and  maintain  it  in  a  repository  so  it  will  be  available  to  M&S  users. 

Dr.  Sanders  suggested  that  we  get  briefed  by  the  Synthetic  Theater  of  War  (STOW)  people  so  we 
can  understand  how  they  intend  to  connect  models  and  what  VVA/C  they  plan  to  do. 

The  VVA/C  actions  from  the  Defense  Master  Plan  Objective  5-2  are  listed  in  Appendix  A.  The 
FY95  W&A  plan  allocates  effort/funds  at  36%  to  standards  and  guidelines;  61%  to  prototype 
applications;  and  3%  to  accreditation  support  services.  The  accreditation  support  services  are 
mainly  in  support  of  CINCs  who  are  asking  how  to  do  M&S  VV&A. 


-55- 


DMSO  is  developing  staff  to  help  carry  out  the  Master  Plan  activities.  There  are  plans  to  have 
academic  support,  support  from  the  SMART  program  team  and  from  ILLGEN.  The  VV&A 
TWG  and  DMSO  are  developing  an  execution  plan. 

Iris  Kameny:  Discussed  the  Objectives  and  Progress  of  the  Data  W &C  Task  Force 

The  three  main  objectives  of  the  Data  VV&C  TF  are  to  (1)  develop  guidelines  for  performing 
data  VV&C  in  coordination  with  VV&A;  (2)  identify  and  collect  information  about  authoritative 
data  sources  and  define  their  responsibilities;  and  (3)  address  the  role  of  M&S  data  centers 
between  data  sources  and  simulation  centers.  The  first  objective  is  being  addressed  by  the  Data 
VV&C  Guidelines  Subgroup  and  the  last  two  objectives  by  the  Authoritative  Data  Sources 
Subgroup. 

The  Data  VV&C  Guidelines  Subgroup  has:  (1)  developed  definitions  for  VV&C  (in  which  a 
distinction  is  made  between  producers  of  data  for  general  use  (e.g.,  DMA  and  DIA)  and  data 
developed  for  use  in  specific  M&S);  (2)  are  developing  a  quality  profile  for  data  in  a 
database/dataset  that  describes  and  asserts  the  VV&C  of  the  data;  (3)  undertaking  tasks  this  year 
to  develop  policies  and  procedures  for  performing  data  VV&C  for  non-DIS  data  users,  DIS  data 
users,  and  data  producers;  and  (4)  supporting  the  identification  and  development  of  tools  to  be 
used  in  data  verification  and  validation  (in  particular  the  portability  of  the  CENTCOM  data 
verification  tool). 

The  Authoritative  Data  Sources  Subgroup  has  been  (1)  developing  definitions  for  authoritative 
data  sources,  data  center,  and  responsibilities  of  data  sources  and  users;  (2)  defining  the 
Authoritative  Data  Source  (ADS)  Directory  metadata,  data  model,  and  taxonomy  of  data 
categories  to  be  used  in  acquiring  ADS  and  searching  for  them;  (3)  addressing  how  to  collect  the 
initial  ADS  information  through  the  Component  M&S  offices  and  populate  the  directory;  (4) 
making  the  ADS  Directory  available  in  near-term  through  the  Interim  M&S  Resource  Repository 
(MSRR)  system;  and  (5)  addressing  the  roles  of  data  sources,  data  centers,  etc.  especially  with 
respect  to  releasability  and  sharing  of  data  (in  coordination  with  the  new  Data  Security 
Requirements  TF). 

General  Discussion: 

Dean  Freed  said  the  Navy  is  trying  to  get  their  ITEM  model  accredited.  Bob  Hartling  (a  co-chair 
of  the  Data  VV&C  Guidelines  Subgroup)  will  be  working  with  him  to  develop  a  VV&A/C  team. 
The  VV&A  group  will  be  developing  procedures  by  building  on  what  has  been  previously  done 
(by  Dale  Pace  for  Navy  VV&A)  and  what  is  occurring  in  the  DIS  community. 

Someone  mentioned  that  two  months  ago  the  JS  formed  two  working  groups  addressing  W&A 
[IRIS'  NOTE:  I  LOST  THEIR  NAMES  AND  OBJECTIVES.] 

It  was  recommended  and  agreed  to  that  there  be  joint  VV&A  and  W &C  meetings  twice  a  year. 
These  could  coincide  with  the  DRTWG  semiannual  meetings.  In  the  interim  each  group  will 
delegate  a  representative  to  work  together  in  order  to  identify  pilot  studies  for  both  groups  to 
participate  in. 

The  VV&A  TWG  will  be  doing  pilot  studies  this  year,  possibilities  include  ALSP  and  ITEM. 

Jim  Watson  said  that  the  A2ATD  is  also  planning  to  do  W&A  implying  that  this  could  also  be  a 
potential  pilot  study. 
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5.5  ACTION  ITEMS 

1.  Dr.  Chien  Huo  will  work  with  Dr.  Pat  Sanders  to  identify  representatives  from  the  two 
groups  that  will  coordinate  the  pilot  studies  being  undertaken. 

2.  Dr.  Chien  Huo/  Ms.  Iris  Kameny  will  coordinate  with  Priscilla  Vanderpool  on  the  next 
joint  VV&A  TWG  and  Data  VV&C  TF  meeting. 
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5.6  APPENDIX  A:  MODELING  AND  SIMULATION  MASTER  PLAN  SUB¬ 
OBJECTIVE  5-2 

Sub-objective  5-2:  Develop  methodologies,  standards,  and  procedures  for  the  VV&A  of  models 
and  simulations  and  the  verification,  validation,  and  certification  (VV&C)  of  data). 


VVA/C  actions  from  the  Defense  Master  Plan  Objective  5-2  are: 

( 1 )  Publish  a  DoD  document  establishing  policy  and  assigning  responsibilities  for  VV &A  of 
M&S.  Coordinate  in  FY95,  promulgate  in  FY96.  (PR:USD(A&T)) 

(2)  Develop  prototype  applications  of  VV&A  to  assess  the  trade-offs  between  the  cost  and 
time  required  for  VV&A  (using  varying  procedures)  of  M&S  in  various  categories  and 
the  M&S  improvement  achieved  under  varying  model  circumstances  (such  as  the 
maturity  and  complexity  of  the  models).  Perform  pilot  VV&A  efforts  in  FY95  and 
FY96.  (PR:  MSWG) 

(3)  Establish  general  VV&A  standards  and  procedures  for  M&S  applications  and  specific 
standards  and  procedures  as  required  for  each  M&S  category  in  FY96.  (PR: 


(4) 

(5) 

(6) 

(7) 

(8) 


USD(A&T))  .  J.  .  .......  _VQ. 

Provide  on-call  technical  support  services  to  accreditation  authonties  beginning  in  FYyo. 

(PR:DMSO) 

Publish  a  DoD  document  setting  policy  and  assigning  responsibilities  for  VV&C  of  data; 
coordinate  in  FY96;  promulgate  in  FY97.  (PR:  USD(A&T) 

Establish  VV&C  standards  and  procedures  for  M&S  applications  in  FY96. 
(PR:USD(A&T)) 

Develop  metrics  for  measuring  data  quality  by  second  quarter  FY96.  (PR:DMSO) 

Once  VV&A  or  VV&C  has  been  performed,  make  histories  of  activities  and  results 
available  to  M&S  community  through  the  resource  repository  system.  Initiate  in  FY95. 
Ongoing.  (PR:  DoD  Components) 
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6.0  NOTES  FROM  AUTHORITATIVE  DATA  SOURCES  SUBGROUP  MEETING  AT 
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6.1  AGENDA 


THURSDAY,  9  FEBRUARY  1995 


1030  -  1200 
1200  -  1230 
1230  -  1330 
1330  -  1345 
1345  -  open 


Data  Sources  Survey  -  Mike  Hopkins 
Lunch 

Data  Sources  Responsibilities  -  Mike  Hopkins 
Break 

Data  Taxonomy  -  All 
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6.3  MAIN  OBJECTIVES  OF  MEETING 

This  meeting  had  three  objectives:  (1)  to  determine  the  status  of  the  JM&S  Data  Sources 
Survey;  (2)  to  discuss  data  source  responsibility  issues;  and  (3)  to  finalize  the  JM&S  taxonomy 
for  data  sources  directory.  Objective  (1)  was  met.  Objective  (2)  resulted  in  an  action  item  due  in 
by  26  April.  Intermediate  deadlines  are  12  April  and  19  April.  Objective  (3)  resulted  in  the 
taxonomy  being  baselined  pending  final  input  from  the  working  group  members,  comments  from 
the  DRTWG,  &  action  items  due  in  by  28  February. 
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6.4  MEETING  NOTES 

A.  JM&S  Data  Sources  Directory: 

The  latest  version  of  the  JM&S  Data  Sources  Directory  was  distributed.  Any  changes  should 
be  directed  to  Mike  Hopkins.  Some  discussion  occurred  on  the  DISA  effort  to  identify 
source  data.  It  was  pointed  out  that  the  DISA  effort  covered  all  of  DoD  and  was  not  limited 
to  M&S  data  sources.  The  DISA  survey  is  a  potential  source  of  data  for  our  efforts. 

Currently  the  directory  resides  in  a  Word  Perfect  word  processor  file.  The  desire  is  to  put  it 
in  a  maintainable  World  Wide  Web  DBMS.  (See  Action  Items.)  This  directory  is  intended 
to  contain  metadata  information  vice  detailed  catalogs.  Pointers  would  be  provided  to  the 
specific  catalog  (e.g.  catalogs  owned  by  the  Defense  Manpower  Data  Center).  It  is  intended 
to  serve  as  a  sort  of  "yellow  pages"  for  the  M&S  community.  A  concern  was  raised  about  the 
World  Wide  Web.  Many  of  the  DoD  field  organizations  are  not  on  the  internet,  much  less 
have  access  to  World  Wide  Web.  Since  it  is  assumed  that  these  organizations  comprise  a 
sizable  number  of  potential  users  of  this  directory,  it  was  suggested  that  a  gopher-type  setup 
of  the  directory  still  be  maintained  through  DMSO’s  MSIS.  Also  mentioned  was  a  meeting 
to  be  held  at  Fort  Huachuca,  AZ  on  the  13th  and  14th  of  February  to  model  this  effort  in  line 
with  the  M&S  directory  effort  being  performed  by  COLS  A. 

B.  Data  Source  Responsibility  Issues: 

An  updated  set  of  definitions  for  authoritative  data  source  and  data  center  was  offered  as  well 
as  updated  responsibilities  for  both  the  data  sources  and  data  customers.  Much  discussion 
was  generated.  The  end  result  was  that  definitions  will  be  provided  for  authoritative  data 
source,  data  source  and  data  center.  Responsibilities  paragraphs  will  be  drawn  up  for  each  of 
these  categories.  An  initial  draft  will  be  ready  for  distribution  to  working  group  members  by 
12  April  1995.  Working  group  members  are  expected  to  respond  by  19  April  1995.  A 
nonresponse  will  imply  concurrence.  (See  Action  Items) 

C.  JM&S  Taxonomy  for  Data  Sources  Directory: 

The  purpose  of  this  issue  was  to  construct  a  taxonomy  of  data  that  would  break  the 
authoritative  data  sources  into  more  manageable  pieces.  The  Army's  data  model  was  used  as 
a  basis  with  input  from  RAND.  The  taxonomy  applies  to  both  U.S.  and  other  countries  (i.e. 
DIA)  data. 

Discussion  on  this  issue  again  took  up  most  of  the  meeting.  The  taxonomy  came  much  closer 
to  finalization  at  this  meeting.  A  couple  of  areas  were  unresolved  due  to  action  items  not 
being  done.  Some  areas  were  modified  slightly.  Modifications  follow.  See  Action  Items  for 
those  areas  requiring  some  amount  of  rework.  The  current  taxonomy  can  be  found  in  the 
Appendices. 

FINANCE:  No  changes  made. 

EQUIPMENT:  No  changes  made. 

TT&P  COGNITIVE:  Minor  spelling  error  corrected  in  definitions.  Otherwise,  no  changes 
made. 

FORCE  DESCRIPTION:  Definitions  of  MASINT  and  SIGINT  needed.  HUMINT  (Human 
Resources  Intelligence)  was  removed.  Its  definition  was  substituted  for  HUMINT  (Human 
Intelligence).  A  line  is  needed  connecting  the  Marine  Corps  box. 
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POLITICAL:  Minor  typographical  errors  /  grammar  corrected  in  definitions. 
DEMOGRAPHIC  is  modified  to  CULTURE/DEMOGRAPHIC.  Definition  to  be  provided. 

HUMAN  FACTORS:  Changes  to  definitions.  In  (d)  perpetual  was  changed  to  perceptual. 

In  (c)  addition  of  stress  and  fatigue. 

INTER-SERVICE  SUPPORT:  Category  renamed  to  SERVICE  SUPPORT.  Much 
discussion  occurred  on  the  subcategories.  New  subcategory  breakdown  to  be  provided. 

SCENARIO:  Addition  of  GUIDANCE,  GOALS,  PRIORITIES  &  OBJECTIVES 
subcategory. 

TEST  RESULTS:  Minor  typographical  errors  in  definitions  corrected.  Addition  of 
subcategory  EXERCISE  to  cover  DIS  exercises,  ATDs,  etc. 

UNIT  PERFORMANCE:  Addition  of  sub-subcategory  OPERATIONS  AND  SUPPORT 
under  the  READINESS  subcategory. 

METADATA/STANDARDS:  No  changes  made. 

MISCELLANEOUS:  Subcategory  SOFTWARE  added. 

ENVIRONMENT:  Minor  typographical  and  grammar  errors  corrected.  Clarification  of 
terms  used  in  TERRAIN  subcategories  made.  SPACE/ATMOSPHERE  category  modified  to 
SPACE  /  UPPER  ATMOSPHERE.  Subcategories  tentatively  redefined.  WEATHER, 
OBSCURANTS  AND  MAN-MADE  CONDITIONS  renamed  to  WEATHER  AND 
OBSCURANTS.  Subcategories  renamed  to  CLIMATOLOGY,  DIURNAL, 
METEOROLOGY,  OBSCURANTS,  and  DAY/NIGHT.  Tentative  redefinitions  of 
subcategories  made.  Definition  of  NAVIGATION  AIDS  sub-subcategory  under 
NAVIGATION  modified  to  include  nautical,  aeronautical  and  other.  IMAGERY  was  added 
as  a  new  ENVIRONMENT  subcategory.  Definition  to  be  provided. 

D.  Other  Business: 

Concerns  were  raised  on  how  the  data  sources  were  being  obtained  for  the  survey.  It  was  felt 
that  focal  points  for  each  of  the  services  (Army,  Navy,  Aar  Force,  Marine  Corps,  DMA,  DIA, 
and  JCS)  were  necessary  to  ensure  that  truly  authoritative  data  sources  were  obtained.  A 
concern  was  that  there  was  no  assurance  that  liaisons  were  made  with  all  authoritative  data 
sources  and  not  with  just  M&S  data  sources.  An  action  item  was  proposed  to  this  effect. 
Possibly  TWSTIAC  and  their  contractor  would  work  with  representatives  from  each  of  the 
above  named  services  to  ensure  that  all  needed  data  sources  are  identified  and  included  in  the 
survey  prior  to  its  being  put  on  WWW.  Known  points  of  contact  were:  Ms.  Lana  McGlynn 
(Army  MSMO),  CAPT  Bossio  and/or  Dr.  Larry  Wiener  (Navy  MSMO),  Ms.  Peggy  Gordon 
(Air  Force  XOM),  Mr  Chris  Gunther  (DIA),  Mr  Bob  Jacober  (DMA),  and  COL  Hanover 
(Marine  Corps  MSMO).  The  JCS  representative  was  TBD. 

The  NEXT  MEETING  is  tentatively  being  scheduled  for  Wednesday,  26  April  1995. 
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6.5  ACTION  ITEMS 

A.  JM&S  Data  Source  Survey: 

1 .  Chien  Huo  -  To  request  that  DMSO  up  the  priority  so  that  the  JDBE  project  could 
build  a  temporary  DBMS  so  that  the  survey  could  be  maintained  on  WWW.  Mike 
Hopkins  will  coordinate. 

B.  Data  Sources  Responsibilities: 

1.  Bob  Hartling,  Matthew  Aylward,  Lana  McGlynn,  Teea  Kim,  Jim  Watson 

representing  Navy,  Marine  Corps,  Army,  Air  Force,  and  user  community  will  rewrite 
definitions  for  AUTHORITATIVE  DATA  SOURCE,  DATA  SOURCE,  and  DATA 
CENTER.  Responsibilities  paragraph  will  be  provided  for  each.  Initial  draft  to  all 
working  group  members  by  12  APRIL  1995.  Comments  required  by  19  APRIL  1995. 
NOTE:  No  response  will  be  taken  as  concurrence. 

C.  Taxonomy  -  ALL  Taxonomy  action  items  are  due  by  28  FEBRUARY  1995;  Mike 

Hopkins  coordinating: 

1.  Bill  Bowers  -  New  subcategory  breakdown  for  SERVICE  SUPPORT.  Will 
coordinate  with  Lana  McGlynn  and  Mike  Hopkins. 

2.  Dave  Danko  -  Extend  DEMOGRAPHIC  subcategory  definition  (under  POLITICAL) 
to  include  CULTURE.  Define  IMAGERY  subcategory  under  ENVIRONMENT. 

3.  Bob  Hartling  -  Provide  definition  of  OPERATIONS  AND  SUPPORT  subcategory 
under  UNIT  PERFORMANCE. 

4.  Allan  Hess  -  Define  SOFTWARE  subcategory  under  MISCELLANEOUS.  Further 
refine  definitions  under  WEATHER  AND  OBSCURANCTS  and  SPACE/UPPER 
ATMOSPHERE  subcategories  under  ENVIRONMENT. 

5.  Mike  Hopkins  -  Define  MASINT  and  SIGINT  subcategories  under  FORCE 
DESCRIPTION.  Work  with  BILL  BOWERS  to  break  down  SERVICE  SUPPORT. 

6.  Lana  McGlynn  -  Work  with  BILL  BOWERS  to  break  down  SERVICE  SUPPORT. 

D.  Other  Business: 

1.  IRIS  KAMENY  -  Coordinate  with  appropriate  representatives  from  each  service 
organization  and  TWSTIAC  to  ensure  that  all  authoritative  data  sources  are  surveyed. 
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6.6  APPENDICES 

A.  M&S  Taxonomy  Definitions: 

1.  FINANCE:  finance  refers  to  funds  that  are  required  to  support  activities  such  as 
Military/Civilian  Pay  Disbursing,  Collection,  Payment  for  Products  and  Services, 

Cash  and  Debt  Management,  Banking,  and  Financial  Institution  Services.  The 
common  thread  through  these  activities  is  the  determination  of  entitlement  to  money, 

a.  SUBCATEGORIES:  TBD 

2.  ENVIRONMENT:  data  that  represents  the  characteristics  and  features  of  the  terrain, 
ocean,  natural  atmospheric  conditions  and  man-made  conditions. 

a.  SUBCATEGORIES:  to  follow  in  a  later  update 

3.  EQUIPMENT:  equipment  is  a  discrete  element  (e.g.  a  sensor,  weapon,  tank,  etc.)  that 
one  can  make  characteristics  &  performance  measurements  on. 

a.  EQUIPMENT  PERFORMANCE:  data  that  represents  how  well  equipment 
performs  its  mission  functions. 

b.  EQUIPMENT  CHARACTERISTICS:  data  that  represents  the  physical 
description  of  a  piece  of  equipment. 

+  Air:  data  regarding  planes,  helicopters  and  other  equipment  which  performs 
its  mission  while  flying;  items  which  are  essential  to  or  support  such 
equipment. 

+  Land:  data  regarding  equipment  which  is  used  by  ground  based  troops; 
items  which  are  carried  by  or  used  by  ground  based  troops. 

+  Sea:  data  regarding  platforms  and  systems  which  are  used  primarily  on  the 
water;  items  which  support  water-based  systems. 

+  Space:  data  regarding  systems  which  perform  its  mission  above  the 
atmosphere;  items  whose  purpose  is  to  support  such  equipment. 

+  Missiles:  data  regarding  missiles. 

+  Electronics/Sensors:  data  regarding  communications,  sensing,  tracking, 
intelligence  gathering  and  electronic  warfare  equipment. 

4.  TACTICS,  TECHNIQUES  AND  PROCEDURES  COGNITIVE  -  Data  that 
represents  the  following: 

a.  TACTICS:  employment  of  units  in  combat;  the  ordered  arrangement  and 
maneuver  of  units  in  relation  to  each  other  or  to  the  enemy. 

b.  DOCTRINE:  fundamental  principles  by  which  military  forces  or  elements 
conduct  operations. 

c.  OPERATIONAL:  description  of  processes  for  carrying  out  mission  functions. 

5.  FORCE  DESCRIPTION:  data  that  represents  the  organization  of  personnel  and 
equipment  that  comprises  force  composition,  unit  composition,  echelonment,  and 
command  relationships. 

a.  SUBCATEGORIES:  to  follow  in  a  later  update 

6.  POLITICAL:  data  pertaining  to  a  state  or  its  government. 

a.  DEMOGRAPHICS/CULTURE:  TBD 

b.  POLICY:  data  pertaining  to  the  administration,  basic  law,  axiom,  or  doctrine  of  a 
StcltC 

c.  ECONOMICS:  data  pertaining  to  the  production,  distribution,  and  use  of  income, 
wealth,  and  commodities  of  a  state. 

7.  HUMAN  FACTORS:  data  that  represents  the  interaction  of  people  with  equipment, 
environment,  or  other  specified  conditions. 

a.  SUBCATEGORIES  to  follow  in  a  later  update 

8.  SERVICE  SUPPORT:  action  by  one  military  service  or  element  thereof  to  provide 
logistic  and/or  administrative  support  within  the  service  or  to  another  military  service 
or  element  thereof.  Such  action  can  be  recurring  or  nonrecurring  in  character  on  an 
installation,  area,  or  worldwide  basis. 


a.  SUBCATEGORIES  TBD 

9.  SCENARIO:  a  description  of  a  military  mission  which  includes  its  purpose,  who  is 
involved,  the  equipment  they  have,  locations  and  times,  environmental  and  political 
constraints  and  guidance  as  to  how  to  perform  the  mission, 

a.  SUBCATEGORIES  to  follow  in  a  later  update 

10.  TEST  RESULTS:  data  that  represents  the  examination,  experimentation,  or  trial 
under  specific  conditions  to  prove  the  value,  ascertain  the  nature,  or  ability  of  the 
system  under  investigation  to  meet  requirements. 

a.  SUBCATEGORIES  to  follow  in  a  later  update 

11.  UNIT  PERFORMANCE:  data  that  represents  the  force  effectiveness, 

a.  SUBCATEGORIES  to  follow  in  a  later  update 

12.  METADATA/STANDARDS:  data  about  data  including  directory  data;  data  about 
data  standards  such  as  process  and  data  models,  standard  data  element  definitions 
such  as  are  found  in  data  dictionaries  (e.g.,  the  Defense  Data  Repository  System 
(DDRS);  symbology  standards;  and  metadata  about  metadata  (e.g.,  standard  data 
element  definitions  for  the  data  fields  defined  in  DODI  8320.1-M-l). 

13.  MISCELLANEOUS: 

a.  SOFTWARE:  TBD 

b.  OTHER 

B.  The  “Almost  Final”  Draft  version  of  the  M&S  Taxonomy 

1.  FINANCE: 

<subcategories  to  be  determined> 

2.  ENVIRONMENT: 

a.  Terrain 

1.  Boundaries 

2.  Elevation 

3.  Hydrography 

4.  Industry 

5.  Physiography 

6.  Populated  Places 

7.  Transportation 

8.  Utilities 

9.  Vegetation 

10.  Soils/Surface  Materials 

b.  Oceanographic 

1.  Geophysics 

a.  Geology 

b.  Acoustics 

c.  Gravity 

d.  Geomagnetics 

2.  Bathymetry 

3.  Oceanography 

a.  Hydrodynamics 

b.  Tides/Surf 

c.  Waves 

d.  Current 

e.  Sediment  Transport 

4.  Water  Column 

a.  Ice 

b.  Visibility 

c.  Biologies 

d.  Water  Quality 

e.  Physical  Parameters 

c.  Weather  and  Obscurants 
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1.  Climatology 

2.  Diurnal 

3.  Meteorology 

4.  Obscurants 

5.  Day/Night 

d.  Space/Upper  Atmosphere 

1.  Upper  Atmosphere 

2  Near  Space 

3.  Space 

e.  EM/EO 

1 .  Natural  Emitter  Characteristics 

2.  Manmade  Emitter  Characteristics 

3.  Receptor  Characteristics 

4.  Communications/Information  Transfer 

5.  Propagation  Effects 

f.  Navigation 

1.  Electronic 

a.  Inertial 

b.  Radio 

c.  Satellite 

2.  Non-electronic 

a.  Obstructions 

b.  Navigation  Aids 

c.  Other 

g.  Imagery 

3.  EQUIPMENT: 

a.  Equipment  Characteristics 

1.  Air 

2.  Land 

3.  Sea 

4.  Space 

5.  Missiles 

6.  Electronics 

7.  Sensors 

b.  Equipment  Performance 

1.  Air 

2.  Land 

3.  Sea 

4.  Space 

5.  Missiles 

6.  Electronics 

7.  Sensors 

4.  TACTICS,  TECHNIQUES,  AND  PROCEDURES  (TTP)  COGNITIVE: 

a.  Tactics 

b.  Operational 

c.  Doctrine 

5.  FORCE  DESCRIPTION: 

a.  Army:  TO&E's  (Table  of  Organization  and  Equipment) 

b.  Marine  Corps:  TO/TE  (Table  of  Organization/Table  of  Equipment) 

c.  Air  Force:  TA  (Table  of  Allowances) 

d.  Navy: 

1 .  COS  AL  (Coordinated  Supply  Allowance  List) 

2.  COSBAL  (Coordinated  Shore  Based  Allowance  List) 

3.  NAAL  (NAVSEA  Ammunition  Allowance  List) 

4.  WSF  (Weapons  System  File) 
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5.  Allowance  Manpower  Document 

6.  POA  (Naval  Air  Program  Operating  Allowance) 

7.  AVCAL  (Aviation  Allowance  List) 

e.  Intelligence:  foreign 

1.  HUMINT  (Human  Intelligence) 

2.  IMINT  (Imagery  Intelligence) 

3.  MASINT  (Measurement  &  Signature  Intelligence) 

4.  SIGINT  (Signals  Intelligence) 

f.  Joint  Forces 

g.  Combined  Forces 

6.  POLITICAL: 

a.  Demographics/Culture 

b.  Policy 

c.  Economics 

7.  HUMAN  FACTORS: 

a.  Sensory 

b.  Perception 

c.  Physical 

d.  Cognitive 

e.  Social 

f.  Emotional 

8.  SERVICE  SUPPORT: 

a.  Subcategories  TBD 

9.  SCENARIO: 

a.  Army 

b.  Navy 

c.  Air  Force 

d.  Marine  Corps 

e.  Joint/Combined 

f.  Operations  Other  Than  War 

g.  Peace  (Planning  Guidance) 

h.  Guidance,  Goals,  Priorities,  and  Objectives 

10.  TEST  RESULTS: 

a.  Operational  Testing 

b.  Developmental  Testing 

p  pYPppicp 

1 1 .  UNIT  PERFORMANCE: 

a.  Readiness 

1.  Personnel 

2.  Training 

3.  Supply 

4.  Maintenance 

5.  Operations  &  Support 

b.  Historical 

12.  METADATA/STANDARDS: 
a.  Subcategories  TBD 

13.  MISCELLANEOUS: 

a.  Software 

b.  Other 
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7.0  NOTES  FROM  DATA  SECURITY  REQUIREMENTS  TASK  FORCE  MEETING 
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7.1  AGENDA 

FRIDAY,  FEBRUARY  10, 1995 
INTRODUCTION 

0800  -  0830  Task  Force  Objectives:  Ms.  Teresa  Lunt  and  Dr.  Chien  Huo 

RELEVANT  TOPICS 
0830  -  0900  Available  Security  Products:  Mr.  Darrell  Sell 
0900  -  0930  Data  Releasability:  CDR  John  Barfoot 
0930  -  1000  TAFIM  Volume  on  Security:  Mr.  Terry  Mayfield 
1000  - 1030  Break 

TOPICS  ASSIGNED  FROM  PREVIOUS  MEETING 
1030  -  1 100  Security  Data  Labeling:  Mr.  Mike  Williams 

1100-  1 130  Lessons  Learned  from  NAVOCEANO's  Integrated  Database  Management 
System:  Ms.  Eleanor  Schroeder 

1 130  -  1200  CCTT  Data  Classification  Issue:  Mr.  Phil  Topper 

WRAPUP 

1200  - 1230  Wrapup:  Led  by  Ms.  Teresa  Lunt  and  Dr.  Chien  Huo 
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7.3  MAIN  OBJECTIVES  OF  MEETING 

The  DSRTG  is  a  forum  for  identifying  and  discussing  data  security  issues  in  the  M&S  data 
community.  It  was  organized  in  December  1994  as  a  DRTWG  Task  Force  with  the  objectives  to 
organize,  analyze  and  translate  data  security  issues  into  requirements.  The  issues  often  have  a 
policy  component  and  a  technology  component.  Data  security  policy  requirements  will  be 
presented  to  the  DMSO  Director  as  a  starting  point  for  working  them  upwards  in  DoD  through 
DDR&E.  The  technology  requirements  will  be  addressed  in  the  ARPA/CSTO  Information 
Security  program  and  testbed  and  shared  with  DoD  and  the  security  community. 

The  co-chairs  of  the  DSRTF  are  Ms.  Teresa  Lunt  (ARPA/CSTO)  and  Dr.  Chien  Huo 
(DISA/DMSO).  The  POCs  representing  the  co-chairs  and  responsible  for  the  running  of  the  TF 
are  Mr.  Terry  Mayfield  (IDA)  for  Ms.  Lunt  and  Ms.  Iris  Kameny  (RAND)  for  Dr.  Huo. 

The  specific  objectives  of  this  meeting  were  to  follow  up  on  the  action  items  assigned  at  the 
previous  meeting:  briefs  on  security  products  (NCSC),  releasability,  TAFIM  Volume  6  (Terry 
Mayfield),  Component  security  policy  (Lana  McGlynn  for  the  Army),  Navy  Integration  Data 
Management  System  (lessons  learned),  standard  way  of  labeling  (Mike  Williams),  ways  to  filter 
and  declassify  data  (Army/C ATT). 

In  the  future,  we  need  to  request  briefings  on  physical  security,  data  aggregation  policy, 

TNTF.T  TNK  and  information  on  other  Components’  security  policies.  There  was  not  sufficient 
time  to  schedule  all  of  the  requested  briefs  at  this  meeting. 

At  the  previous  meeting  it  appeared  that  MITRE  would  perform  a  near-term  project  to  categorize 
individual  M&S  data  systems  data  security  requirements  and  suggest  technology  solutions  and 
RAND  would  address  defining  the  policy  issues  and  suggested  changes.  Since  then  it  was 
learned  that  the  FFRDCs  are  unable  to  perform  this  near-term  effort  and  the  Co-chairs  are 
looking  into  having  the  initial  work  done  by  NRL. 
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7.4  MEETING  NOTES 

Ms.  Iris  Kameny:  Overview  Brief 

The  ARP  A  objectives  in  working  with  DMSO  are  (1)  to  use  the  DSRTF  as  a  forum  to  match  up 
database  security  technology  players  with  M&S  players  and  (2)  to  use  M&S  data  security 
requirements  to  plan  a  testbed  project  involving  real  M&S  users  having  problems  and  some 
experimental  database  security  technology  as  solutions. 

Data  security  related  findings  of  the  recent  DSB  Summer  Study  on  Information  Architecture  for 
the  Battlefield  included  recommendations  for  more  DoD  investment  in  classification 
management  for  data  objects,  data  integrity  (to  include  pedigree,  currency  and  confidence  levels 
for  data),  and  data  contamination  recovery  procedures  (due  to  system  failure,  tampering,  or  use 
of  inaccurate/incomplete  data).  The  first  two  areas  are  being  addressed  by  the  DMSO  DRTWG 
but  the  last  one  is  not  being  currently  being  addressed  by  any  DRTWG  TF. 

Ms.  Teresa  Lunt 

Ms.  Lunt  suggested  to  the  M&S  members  of  the  DSRTF  that  they  begin  to  think  about 
participating  in  the  testbed.  Interest  was  shown  by  Ms.  Janet  Morrow  (National  Ground 
Intelligence  Center)  and  Ms.  Lana  McGlynn  (Army  M&S  Management  Office).  An  important 
purpose  of  the  testbed  will  be  to  establish  security  methodology  and  products  (such  as  certified 
guards)  that  will  be  acceptable  to  the  security  and  M&S  communities.  However,  during  the 
testbed  process  the  M&S  systems  that  are  participating  may  have  to  face  a  near-term 
accreditation  problem.  An  M&S  system  may  not  be  accredited  to  operate  under  the  security 
methods  being  explored  in  the  test  bed.  This  problem  will  have  to  be  worked  out  for  individual 
systems  as  necessary. 

Mr.  Darrell  Sells:  Available  Security  Products 

Mr.  Sells  gave  an  overview  of  why  security  is  needed,  risk  management,  and  threats.  He  then 
discussed  protections:  better  security  management  (e.g.,  enforcement  of  security  policy), 
cryptography  for  file  protection  and  privacy  (DES,  Pretty  Good  Privacy,  Crypt  (SUN)); 
communication  protection  (public  key,  digital  signature,  networks,  phone  lines,  cable  TV, 
satellite).  Authentication  and  identification  protection  includes  Fortezza  using  PCMCIA  cards 
and  biometrics  (such  as  fingerprint,  retina  scan,  etc.).  He  gave  us  a  list  of  security/criteria 
guidelines,  including  Trusted  Computer  Security  Evaluation  Criteria  (TCSEC),  Trusted  Network 
Interpretation,  Trusted  Database  Interpretation  and  others  from  the  European  and  Canadian 
communities.  Applications  of  security  include  MLS  DBMS  products:  B1  industry  DBMS 
(Sybase,  Informex,  and  Oracle);  High  Assurance  B3/A1  DBMS  (Lock  (SCC),  MUSET  (MITRE) 
and  SINTRA  (NRL);  and  others,  including  Ingress  Intelligent  Database,  Trusted  Rubix  B2, 
TRUDATA/SQLSentry  (ARC),  DEC  SERdb,  DBC/1012  (Teradata).  There  are  three  upcoming 
operating  systems:  Theta  (ORA),  Synergy  (NSA),  and  TMACH  (TIS)  as  well  as  evaluated 
products  at  B1  level  (System  5  MLS,  and  Secureware),  at  B2  (Trusted  Xenix),  at  B3  (XTS  300), 
and  at  A1  (GEMSOS).  Network  components  include  firewalls  (Firewall  toolkit  (TIS), 
Sidewinder  (SCC),  Firewall  1  (sold  by  Sun);  and  others  available  through  Mosaic  and  people  can 
build  their  own.  He  included  an  evaluated  products  list  for  operating  systems,  networks,  and 
subsystems. 

Mr.  Sells  said  that  NSA  is  beginning  to  use  the  security  products  and  devices  inhouse  to  better 
ascertain  usability  or  lack  there  of,  etc. 

CDR  John  Barfoot:  Foreign  Disclosure 

CDR  Barfoot  could  only  speak  officially  on  foreign  disclosure  of  data.  There  is  no  existing 
policy  on  internal  sharing/release  of  data  within  DoD  except  for  complying  with  security  policy. 
He  and  others  that  Iris  Kameny  spoke  with  in  trying  to  set  up  this  briefing  were  unaware  of  any 
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difficulties  in  sharing  and  exchanging  data  within  DoD  because  there  are  no  restrictions  other 
than  security  policy.  They  all  thought  it  was  happening  without  difficulty. 

CDR  Barfoot  went  over  national  disclosure  policy,  in  particular  NDP-1  (1  Oct  1988),  that 
promulgates  policy  and  procedures,  criteria  and  limitations,  and  release  arrangements  for  eight 
specific  information  categories.  There  are  also  many  policies  in  specific  areas  (such  as 
telecommunications)  that  require  special  searching  for  when  you  need  them.  He  gave  us  a  short 
list  of  do’s  and  don'ts  and  offered  basic  procedures:  if  a  foreign  country  requests  release  of  your 
data,  your  organization  should  forward  the  request  to  its  OCA,  and  its  OCA  will  determine 
releasability/sanitization  requirements.  He  did  caution  that  when  you  call  your  OCA,  he/she  may 
say  determining  releasability  is  not  his/her  job  -  so  be  persistent.  Allen  Hess  says  that  most 
OCAs  have  failed  to  furnish  releasability  statements.  There  is  a  requirement  for  this,  but  no 
enforcement. 

With  proprietary  information/products,  the  contractor  will  have  to  contact  the  Defense 
Technology  Security  Administration  for  permission  before  release  to  a  foreign  party. 

CDR  Barfoot  said  for  joint  information  release  of  TADILS  and  USMTFs,  he  knows  the  POCs 
for  all  DoD  agencies. 

Mr.  Terry  Mayfield:  Overview  of  the  Defense  Goal  Security  Architecture  (DGSA) 

Focusing  the  Direction  for  Securing  Information  Systems 

This  was  a  very  good  one  hour  briefing  on  the  DGSA  which  is  documented  in  the  TAFIM 
Volume  6.  Mr.  Mayfield  began  by  discussing  the  DoD  security  policy  statements  from  the 
DISSP  SP.l,  which  is  understood  to  be  in  coordination.  It  is  not  likely  that  DISSP  SP.l  will  be 
released  in  its  entirety,  rather  it  is  more  likely  to  end  up  being  integrated  into  other  DoD  security 
policy  documents,  e.g.,  DoD  5200- 1-R  and  DoDD  5200.28: 

DoD  information  systems  must:  [REQUIREMENTS  WERE  DERIVED  FROM  DOD 
CUSTOMERS.] 

Be  sufficiently  protected  to  allow  connectivity  via  common  carrier  (public)  communication 
systems  [MAJOR  CHANGE  IN  DOD  PERSPECTIVE] 

Be  sufficiently  protected  to  allow  distributed  information  processing  among  multiple  hosts  on 
multiple  networks  in  accordance  with  open  systems  architecture. 

Support  information  processing  under  multiple  security  policies  of  arbitrary  complexity, 
including  those  for  sensitive  unclassified  information  and  multiple  categories  of  classified 
information. 

Support  distributed  information  processing  among  users  employing  resources  with  varying 
degrees  of  security  protections,  including  users  of  non-secure  resources  if  a  particular 
mission  so  dictates. 

The  underlying  principle  of  the  DGSA  is  that  the  missions  of  the  enterprise  provide  the 
architectural  foundation  for  information  system  security  requirements  and  for  system  property 
cost-benefit  trade-offs.  Architectures  provide  a  means  to  think  about  something  before  building 
it.  He  showed  a  flow  diagram  of  the  information  security  engineering  process  moving  from  DoD 
mission  definition  to  system  and  component  acquisition  and  accreditation. 

The  DGSA  fundamentals:  the  DGSA  specifies  security  principles  and  target  security  capabilities 
that  must  exist  in  future  DoD  information  systems;  it  doesn’t  specify  any  particular  information 
system  or  component;  it  is  an  integral  part  of  the  TAFIM;  and  it  provides  a  generic  "security 
roadmap"  for  system  security  architects.  The  fundamental  logical  concepts  defined  for  the 
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DGSA  are:  information  domains,  strict  isolation,  security  context,  security  association,  security 
management,  absolute  protection,  and  uniform  accreditation.  [These  are  all  defined  in  the 
briefing  charts.] 

The  definition  of  "information  domain"  as  a  set  of  identified  users  and  their  information  objects 
uniquely  bound  by  a  security  policy,  is  the  basis  for  the  DGSA.  A  "security  context"  is  the 
collection  of  all  hardware/software  resources  needed  to  support  an  end  user  or  system  function 
operating  in  a  particular  information  domain  in  accordance  with  a  specific  domain  security 
policy.  A  "security  association"  is  the  set  of  all  information  system  resources  employed  to 
securely  link  two  distinct  security  contexts  on  different  end  systems  supporting  the  same 
information  domain.  Security  management  objects  supporting  a  particular  information  domain 
are  contained  in  a  logical  repository  called  a  Security  Management  Information  Base  (SMIB). 
Security  management  information  must  be  in  a  protected  domain.  Security  management 
information  domains  contain  privileged  end  users,  security  management  information  objects  and 
a  security  policy.  A  single  security  management  domain  can  address  multiple  distributed 
information  domains. 

DGSA  security  services  include:  identification  and  authentication,  access  control,  data  integrity, 
data  confidentiality,  non-repudiation,  and  availability.  DGSA  provides  more  effective  mission 
support  and  user  capabilities  by  adopting  a  mission-oriented  view;  structure  and  guidance  for 
security  in  open  systems,  including  interoperability  requirement;  definition  and  structure  for 
security  management  in  information  systems  and  a  basis  for  evolvable  and  consistent  security 
evaluation  and  accreditation  of  components  and  systems. 

Mr.  Mayfield  said  that  the  DISA/JIEO/CISS  organization  that  developed  DGSA  has  now  been 
reorganized.  The  DISA  D3  Operations  now  has  a  new  IW  organization  and  most  of  the  CISS 
people  went  there.  The  architecture  and  engineering  organization  responsible  for  the  DGSA  has 
been  retained  in  JIEO.  The  core  team  for  transitioning  to  DGSA  will  be  composed  of  people 
from  DISA,  NSA,  FFRDCs  and  a  set  of  Defense  Contractors.  There  is  a  DGSA  transition  plan,  a 
set  of  research  priorities  (including  information  domains,  key  management  in  distributed  system, 
efficient  security  management,  and  object  oriented  technologies);  and  near  term  challenges. 

An  important  question  for  the  M&S  community  is  the  scope  of  information  domains  and  how  to 
handle  the  sharing  relationships  (i.e.,  policy)  between  distinct  information  domains  if,  for 
example  in  a  DIS  exercise,  one  is  interoperating  across  models  from  different  Components  using 
data  from  many  different  sources. 


Mr.  Mike  Williams:  Security  Data  Labeling 

Mr.  Williams  discussed  a  new  standard  that  can  address  this  problem.  It  is  MIL-STD-2045- 
48501,  Military  Standard  Common  Security  Label  (CSL)  25  January  1995.  (Much  of  this 
information  was  supplied  to  Mr.  Williams  by  Dr.  Tom  Bartee  of  IDA  and  NSA  sponsors.)  The 
scope  of  the  CSL  includes  the  intelligence  community  and  DoD,  others  (DOJ,  DEA,  NIST) 
provided  inputs  and  others,  including  DOE  and  DOS,  may  participate.  CSL  is  designed  to  work 
with  current  and  developing  TCP/IP  or  OSI  communication  systems.  It  is  consistent  with 
standards  for  encryption  and  guard  protocol  labeling.  Its  communication  format  is  suitable  for 
end-system  storage  and  display  of  security  labels.  Security  policies  and  procedures  are  contained 
in  CSL  for  interconnecting  to  system  high  nets  or  nodes,  TCP/IP  error  control  codes  and 
procedures,  etc.  Future  trusted  systems  may  have  a  different  approach  than  current  systems,  but 
will  be  consistent  with  CSL. 


Terry  Mayfield  has  added  the  following  comment  as  a  result  of  reviewing  these  notes: 

THE  CSL  Wl  NOT  REMAIN  VALID  ONCE  SYSTEMS  BECOME  "DGSA  CONSISTENT 
SINCE  THE  CSL  IS  OPERATING  AT  THE  ROUTER  LEVEL  AND  THE  DGSA  DOES  NOT 
IMPOSE  SECURITY  REQUIREMENTS  AT  THE  ROUTER  LEVEL.  THE  IDEAS  BEHIND 
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CSL  MAY  BE  USEFUL  IN  THE  DEVELOPMENT  OF  FUTURE  SECURITY  ASSOCIATION 
MECHANISMS,  BUT  THAT  REMAINS  TO  BE  SEEN. 

CSL  is  real  and  in  operation,  works  with  current  TCP/IP  systems,  is  being  used  in  many  new 
military  systems,  and  is  being  supplied  by  many  contractors. 

The  CSL  is  a  Protocol  Data  Unit  (PDU)  in  a  TCP/IP  or  OSI  packet  that  provides  a  Domain  of 
Interpretation  identifier  (DOI  id)  and  zero  or  more  tags.  The  CSL  consists  of  a  CSL  header  (set 
aside  by  OSI),  followed  by  an  octet  of  length,  followed  by  4  octets  of  the  DOI  id  (which  can 
contain  standard  domain  ids  already  defined  by  DISA),  followed  by  a  number  of  tag  label  bits 
interpretable  within  the  DOI.  Most  complexities  of  compartments,  categories,  hierarchies/levels, 
and  release  markings  can  be  expressed  in  the  four  pre-defined  tag  types.  CSL  provides  for 
unlabeled  inputs  and  procedures  for  labeling  them  before  output.  Some  distribution  and/or 
handling  caveats  (e.g.,  FOUO,  NOFORN)  may  require  approaches  to  be  exemplified  in  the 
handbook.  Some  new  programs  may  require  new  DOIs  (to  be  registered  with  DISA  for  a  unique 
id#)  and/or  new  tag  types.  CSL  specifies  format,  processing  and  procedures  for  CSL  generally, 
and  for  Mandatory  Access  Control  (MAC)  and  Release  Marking  Security  Policy  (it  requires 
MAC/  Release  enforcement  at  Network  Layer  3/router  level)  but  the  CSL  does  not  specify 
trust/assurance  or  trustworthiness  of  labels. 

Mr.  Williams'  summary  recommends  that  M&S  labeling  efforts  should  exploit  CSL  in  COTS 
buys,  retrofits,  and  developments.  He  notes  that  while  CSL  is  mainly  a  communication  standard, 
it  could  be  adopted  at  the  interface  to  all  old  unlabeled  input/outputs,  storage  media  and  displays. 
One  could  also  consider  CSL  format  for  external  representation  in  trusted  systems  that  already 
have  internal  label  conventions. 

Mr.  Williams  gave  us  a  copy  of  MIL-STD-2045-48501.  Anyone  desiring  a  copy  of  this 
document  should  contact  Dr.  Chien  Huo  at  DMSO. 

Ms.  Eleanor  Schroeder:  Navoceanos  Integrated  Database  Management  System 
Lessons  Learned:  Security 

The  Naval  Oceanographic  Office,  located  at  Stennis  Space  Center  in  Mississippi,  is  a  third 
echelon  command  reporting  to  the  Commander,  Naval  Meteorology  and  Oceanography 
Command,  who  in  turn  reports  to  the  Chief  of  Naval  Operations  (OP-096).  NAVOCEANO  has  a 
global  mission  for  collection,  processing,  and  dissemination  of  oceanographic  and  MC&G 
environmental  products.  Specifically,  its  mission  is  to  provide  specialized  and  unique 
oceanographic  support  to  unified/specified  commands  in  a  manner  and  timeframe  that  allows 
them  to  meet  their  warfighting  objectives.  This  product-oriented  mission  drives  the  Production 
Modernization  Initiative  (PMI)  and  is  the  basis  for  use  of  the  Integrated  Database  Management 
System  (IDBMS).  The  PMI/IDBMS  approach  is  driven  by  the  need  for  a  practical  means  to 
view  the  ocean  environment  as  a  fully  integrated  4-D  cube  (three  spatial  dimensions  plus  time). 
Over  the  intermediate  to  long-range  planning  interval,  this  capability  supports  integration  of  the 
various  ocean  data  sets  for  visualization,  analysis,  and  decision  support. 

The  development  of  the  IDBMS  was  not  an  easy  process.  The  original  plans  called  for  a  single 
relational  database  that  would  contain  all  of  the  various  ocean  and  MC&G  data  sets  and  products 
that  resided  at  NAVOCEANO.  This  would  have  required  a  huge  amount  of  disk  storage  as  well 
as  a  multi-level  secure  operating  system  with  a  trusted  database.  The  primary  prohibitive  factor 
that  redesigned  the  concept  was  the  cost  of  disk  storage  at  the  time  (early  80s).  Since  the  system 
was  not  expected  to  be  "on-line"  until  the  mid  to  late  80s,  it  was  anticipated  an  MLS  operating 
system  and  trusted  database  would  be  available.  The  system  was  redesigned  to  become  more  of 
a  distributed  database  system.  Its  supporting  software  would  include  an  MLS  operating  system, 
a  Trusted  Computing  Base  (TCB),  a  relational  DBMS,  and  common  production  tools.  A  multi¬ 
user  capability  supported  by  centralized  data  ingest,  storage,  management,  cataloging,  product 
generation,  and  archive  functions  would  be  provided.  Users  would  access  IDBMS  by  logging  in 
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via  the  TCB  for  their  particular  information  system.  The  TCB  would  determine  the  user's  access 
to  both  data  and  services  based  on  need-to-know  and  security  access.  A  windowing  environment 
would  allow  users  to  select  data  and  application  programs  in  order  to  process  data.  It  should  be 
noted  that  at  this  point  no  set  hardware  was  selected  for  the  TCB  machinery.  It  was  hoped  that 
all  hardware  would  interact  efficiently,  which  of  course  turned  out  not  to  be  the  case.  Hardware 
ranged  from  IBM-compatible  PCs  to  Macintoshes,  from  PDP-1  Is  to  VAX  750s  to  HPs,  Suns, 
Silicon  Graphics,  Harris,  Intergraph,  and  Evans  and  Sutherland  workstations.  An  eventual 
decision  was  made  to  utilize  an  Intergraph  or  a  Sun  workstation  since  all  information  systems 
owned  at  least  one  of  these.  This  eventually  evolved  to  a  Sun  workstation  due  to  compatibility 
issues. 

Three  information  systems  were  initially  selected  to  participate  in  phase  I  of  the  IDBMS.  The 
systems  were  chosen  due  to  the  fact  that  they  interacted  with  each  other  and  were  of  multiple 
security  levels.  All  information  systems  had  been  going  through  "interviews"  by  this  point  to 
develop  functional  decompositions,  determine  transition  both  internally  and  externally,  and  to 
develop  security  models.  Contracts  were  awarded  and  the  real  system  design  began.  By  this 
time  it  was  the  early  90s.  As  time  progressed,  it  was  determined  that  no  production  version  of  an 
MLS  operating  system  would  be  available  at  the  expected  time  of  implementation.  This  was 
cause  for  much  discussion  on  what  direction  the  IDBMS  would  end  up  taking.  The  eventual 
"solution"  was  to  temporarily  scrap  the  multi-level  security  concept  and  to  create  two  separate 
IDBMS  -  a  classified  one  and  an  unclassified  one.  This  definitely  defeated  the  purpose  for  which 
IDBMS  was  intended,  but  the  technology  was  just  not  there.  SunOS  CMW  was  in  Beta  release. 

A  final  production  release  was  expected  by  early  1994.  Similarly  Trusted  Oracle  7  was  in  Beta 
release;  its  production  version  was  expected  by  March  1994.  It  was  decided  to  go  with  these 
software  systems  based  on  the  fact  that  the  contractor  would  be  working  closely  with  each  of  the 
vendors  to  resolve  problems  that  may  occur  with  the  Beta  versions.  Security  labeling  was 
waived  as  a  requirement  due  to  the  delayed  availability  of  a  reliably  functional  trusted  operating 
system.  Row  labeling  would  occur  with  the  relational  DBMS  tables.  Although  this  was  not  a 
final  solution,  it  was  felt  that  this  would  "pave  the  way"  for  a  future  upgrade  to  a  B1  level 
system.  To  throw  another  kink  into  the  works,  a  massive  reorganization  occurred  within  the 
office.  Prior  to  this  reorganization,  departments  and  divisions  were  pretty  much  in  sync  with  the 
information  system  they  represented.  For  example,  there  were  acoustics  divisions  to  deal  with 
acoustics  data,  gravity  divisions  to  deal  with  gravimetric  data,  etc.  The  reorganization  aligned 
the  departments  and  division  within  functional  lines.  There  were  now  divisions  dealing  with  data 
collection,  data  evaluation,  product  generation,  etc.  Thus  an  information  system  that  dealt  with 
oceanographic  data  that  once  was  geographically  located  in  one  part  of  a  building  would  now  be 
found  spread  throughout  a  building  or  even  in  some  cases  throughout  several  buildings.  Thus 
additional  cabling  was  necessary  in  order  to  keep  the  TCBs  tied  to  the  various  information 
system  machines.  This  problem  is  still  being  worked  out  -  TCBs  may  or  may  not  now  be  tied  to 
a  specific  information  system.  This  causes  some  headaches  for  the  system  managers  and 
administrators  as  well  as  the  ADPSSOs,  but  it  is  believed  that  it  will  eventually  work  out. 

Security  documents  have  been  generated  to  aid  in  implementing  security  requirements  and 
procedures.  A  PMI  Informal  Security  Model  was  developed  for  the  integration  of  security 
procedures  employed  by  this  office  to  fulfill  the  requirements  defined  in  the  PMI  Security  Policy, 
the  PMI  System  Specification  and  DoD-5200.28-STD.  The  PMI  Security  Policy  is  a  statement 
of  intent  with  regard  to  control  over,  access  to,  and  dissemination  of  information  processed  by 
NAVOCEANO  information  systems  participating  in  PMI  and  reflects  the  laws,  regulations,  and 
general  policies  from  which  the  PMI  security  policy  is  derived.  Other  overreaching  documents 
exist  for  the  activity  that  deal  with  general  computer  security  and  networking  security.  • 

The  lessons  learned?  Most  are  obvious.  In  designing  a  system,  do  a  lot  of  research  to  determine 
what  is  available  technology-wise  and  what  will  be  available  within  a  reasonable  period  of  time. 
Design  your  system  to  be  flexible.  Ensure  your  performance  and  storage  "requirements"  are 
reasonable.  In  the  case  of  IDBMS,  the  early  design  was  developed  by  a  room  full  of  scientists 
who  were  asked  what  kind  of  system  they  desired.  The  obvious  answer  after  years  of  working  on 
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a  UNIVAC,  was  unlimited  storage  space,  enough  memory  to  ensure  negligible  paging,  nearly 
instantaneous  response  times,  total  interconnectivity  regardless  of  platforms,  and  whatever 
software  they  wanted.  It  was  a  rude  awakening  when  the  system  that  evolved  did  not  meet  most 
of  their  expectations.  The  most  important  factor  though  with  security  issues  is  that  of  the  human 
factor.  Most  field  organizations  have  their  own  security  manuals  and  policies  that  are  tailored 
from  the  DoD  standards  to  fit  their  specific  needs.  The  reason  behind  this  is  that  the  DoD  level 
standards  are  usually  very  general  guidelines.  Releasability  and  need-to-know  issues  are  usually 
not  addressed  at  that  level  and  are  left  to  the  lower  levels  to  determine.  No  security  officer  is 
willing  to  take  full  responsibility  for  another  employee's  actions  in  the  field  of  security  issues, 
particularly  data  security  issues.  Thus  the  security  person  will  interpret  the  guidelines  in  such  a 
way  that  he/she  is  protected.  Until  the  DoD  level  creates  a  more  stringent  set  of  rules  to  which 
field  organizations  can  adhere  with  little  or,  preferably,  no  interpretation  needed,  releasability 
and  need-to-know  will  always  be  an  issue  when  dealing  with  DoD  data. 

Mr.  Phil  Topper:  Generic  Vulnerability  Data  for  Close  Combat  Tactical  Trainers  (CCTT) 
The  CCTT  is  a  simulation  system  wherein  various  simulated  elements  replicating  actual  combat 
vehicles,  weapon  systems,  and  command  and  control  elements  are  networked  for  real-time,  fully 
interactive  collective  task  training  on  computer  generated  terrain. 

The  Army  needs  to  build  training  systems  that  use  unclassified  data  for  cost  reasons  but  the  data 
must  be  of  high  enough  quality  so  that  its  use  will  not  cause  negative  training.  CCTT  is  using 
standard  Army  methodologies,  doctrine,  etc.  Their  data  files  must  be  structured  the  same  as  the 
classified  database  structures.  The  mindset  is  to  train  with  unclassified  data  but  in  a  real  situation 
to  be  able  to  replace  unclassified  data  with  classified  data  without  a  problem. 

Everywhere  CCTT  went  for  data  they  found  it  was  classified.  A  big  issue  was  how  to  support 
PM  CATT  in  getting  unclassified  data.  This  is  a  discussion  of  how  classified  weapon 
performance  data  was  changed  into  generic  vulnerability  data  for  use  in  CCTT.  CCTT  requires 
data  in  the  following  categories:  target  acquisition;  delivery  accuracy;  vulnerability  (direct  fire, 
indirect  fire,  and  mines);  combat  damaged  components  and  repair  times;  and  personnel 
casualties.  It  was  determined  that  the  data  is  classified  because  it  represents  specific 
weapon/target  specification.  If  the  data  is  averaged  over  weapons  and  targets  then  if  can  be 
unclassified.  So  long  as  there  is  no  way  to  infer  or  relate  a  specific  weapon  to  a  specific  target 
and  conditions  it  will  work.  In  the  cases  where  there  are  a  limited  number  of  vehicles  of  a 
specific  kind,  this  could  be  a  problem  because  of  statistical  inferencing. 

Mr.  Topper  outlined  the  generic  process  for  developing  unclassified,  generic,  vulnerability  data 
for  armored  systems: 

•  Identify  list  of  blue  forces  and  opposing  forces  platforms  and  munitions 

•  Develop  vehicle  vulnerability  classification  scheme  based  on  degree  of  armor  protection 
and  ammunition  location  and  storage 

•  Develop  broad-based  munitions  classes  based  on  size,  type  and  performance 

•  Develop  criteria  to  smooth  classified  probability  hit/kill  files  using  view  averaging 
techniques  and  weapon  system  dispersion 

•  Develop  criteria  to  define  overmatching  vs  undermatching  for  rounds  vs  targets 

•  Construct  IUA  files 

•  Check  overmatching  files  to  ensure  opposing  forces  vs  blue  forces  munition  target  values 
for  K  kills  are  not  representative  of  actual  capability.  Adjust,  if  necessary  based  on 
opposing  forces  values.  This  problem  occurs  when  the  vehicle  set  is  small  and  represents 
US  vehicles  only 

The  data  underwent  a  pretty  thorough  scrub  allowing  AMSAA  to  provide  the  data  directly  to 
CATT.  This  is  not  following  general  Army  policy  but  is  determined  through  management 
review  decisions  that  support  AMSAA's  being  responsive  to  requests  for  unclassified  data. 
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Questions  were  asked  about  the  criteria  developed  allowing  the  change  of  classified  to 
unclassified.  Could  they  go  back  and  come  up  with  formally  stated  criteria  for  allowing  the  label 
change?  Mr.  Topper  said  no,  this  is  not  a  standard  approach  but  is  done  on  a  case  by  case  basis. 

It  results  in  making  the  data  available  and  "no  one  going  to  jail"  for  doing  so.  However,  they  are 
documenting  all  the  approaches  they  have  considered  and  taken  and  have  an  internal  audit  trail  of 
what  has  been  done. 

They  are  now  looking  at  affects  against  high  performance  fixed  wing  aircraft  and  rotating  wing 
aircraft  and  have  been  provided  large  amount  of  information  on  specific  systems. 

It  was  noted  that  the  Intelligence  Community  has  done  a  180  degree  turn  with  respect  to 
supplying  unclassified  data  to  operational  users. 
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7.5  WRAPUP 

There  was  little  time  for  wrapup.  The  next  meeting  will  either  take  place  during  the  week  of  the 
August  DRTWG  meeting  or  sooner  if  there  is  good  reason  (e.g.,  if  the  security  projects  get 
underway,  the  ARPA  testbed  is  better  formulated,  etc.).  Please  let  Mr.  Terry  Mayfield  and/or 
Ms.  Iris  Kameny  know  if  you  have  a  particular  data  security  need  that  can  be  addressed  at  this 
forum. 

Component  Security  Regulations: 

Ms.  Janet  Morrow  gave  Ms.  Iris  Kameny  a  one  page  table  of  contents  from  the  FSTC  Security 
Manual,  dated  1  January  1994  showing  the  categories  of  security  policy. 

Ms.  Lana  McGlynn  also  gave  Ms.  Iris  Kameny  a  copy  of  two  Army  regulations  that  address 
security 

Army  Reg  380-10,  30  December  1994,  "Technology  Transfer,  Disclosure  of  Information  and 
Contacts  with  Foreign  Representatives  " 

Army  Reg  380-10, 1  August  1990,  "Information  Systems  Security  " 

Lana  suggested,  that  we  got  corresponding  documents  from  each  of  the  other  Components,  and 
then  have  a  small  group  review  these  for  inconsistencies,  and  identify  where  they  think  policies 
could  be  improved  to  support  M&S  data  requirements. 
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7.6  ACTION  ITEMS 

1.  Mr.  Terry  Mayfield/Ms.  Iris  Kameny:  Follow  up  on  getting  briefs  at  next  meeting  on: 
physical  security,  data  aggregation  policy,  and  INTELINK.  There  was  not  sufficient  time 
to  schedule  all  of  the  requested  briefs  at  this  meeting. 

2.  Dr.  Chien  Huo:  Ask  DMSO  to  request  Component  regulations  on  information  systems 
security  from  the  Component  M&S  offices. 
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8.1  AGENDA 

MONDAY  -  TUESDAY,  AUGUST  15-16,  1994 
I/DB  TASK  GROUP  M&S  REPOSITORY  DESIGN  SESSION 

MONDAY,  AUGUST  15,  1994 

0830  -  0930  Data  Exchange  Formats  for  Logical  Data  Models:  Mr.  Peter  Valentine 
0930  -  1 100  Flexible  work  time 
1 100  -  1300  Identification  of  technical  issues 
1300  -  1400  Lunch 

1400  - 1600  Discussion  of  MITRE  Task  Products:  Mike  Gorman 
1600  -  1730  Open  time 

TUESDAY,  AUGUST  16, 1994 
0830  -  0845  Collecting  Data  Via  Mosaic:  Kelli  McTigue 

0845  -  1 130  Communications  options  for  classified  repository  data  interchange  software, 
hardware,  protocols,  networks: 

DIS  Tom  Tieman 
Other  Steve  Roa 

1130-  1300  Lunch 

1300  -  1430  MMI  for  Repositories: 

ARMS  Demo  Mike  Stansel 
other  MMIs  Need  volunteers 

1430  -  1500  UTSS  Updates:  Jim  Santangelo 

1530-  1600  MSIM  report:  Jim  Augins 

1600  - 1730  Need  volunteers  for  presentation  or  open  work  time:  Send 

potential  briefs  or  discussion  topics  to  Jim  Augins 

augins  @nosc.mil,  phone:  (619)  553-2673,  fax:  (619)  553-8221 
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8.3  MAIN  OBJECTIVE  OF  MEETING 

A  major  portion  of  the  meeting  was  devoted  to  defining  a  road  map  to  develop  an  M&S 
Information  Resources  Repository  (IRR).  This  was  in  response  to  Ghien  Huo's  urgent  email 
before  the  meeting  to  be  sure  we  reviewed  the  MITRE  repository  effort  and  gave  him  guidance 
as  to  how  the  Repository  Subgroup  thought  that  work  fit  into  the  short  term  effort  for  a  prototype 
IRR  (PIRR)  and  the  longer  term  effort.  We  made  this  the  major  objective  of  the  meeting. 
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8.4  NEXT  STEPS  IN  ANSWERING  THE  MAIN  OBJECTIVE 

We  discussed  the  next  steps  using  the  waterfall  software  process  as  a  guideline.  Essentially,  we 
held  the  end  point  of  a  prototype  FDAd  IRR  constant  at  96  January  1,  and  worked  forward  from 
Sept  94  to  Jan  96. 

There  was  disagreement  among  the  group  as  to  whether  the  requirements  analysis  should  be  for 
the  entire  long  range  M&S  IRR  or  just  for  the  prototype.  The  main  supporter  of  the  long  range 
analysis  was  Linda  Calvert.  She  made  the  point  that  there  is  a  political  sensitivity  to  developing 
the  PIRR  for  the  FDAd  since  DIS A  would  prefer  we  used  the  DDRS  for  the  FDAd  IRR. 

Therefore,  if  the  PIRR  only  addresses  FDAd  needs  without  being  the  result  of  a  long  range 
requirements  analysis,  we  may  cause  a  big  stir.  However,  the  Group  felt  that  because  there  is 
such  a  short  time  to  get  the  prototype  done,  getting  side-tracked  on  long  term  issues  before  we 
have  the  prototype  experience  could  cause  a  big  delay  and  more  costs.  We  did  compromise  on 
the  following:  (1)  put  major  effort  into  the  prototype,  (2)  concurrently  with  the  prototype 
requirements  analysis  effort  also  run  a  long  term  requirements  analysis  effort,  and  (3)  have  the 
two  tasks  interact  so  that  the  prototype  effort  doesn't  do  something  entirely  orthogonal  to  long 
term  findings.  (However,  doing  this  will  require  more  DMSO  funding  and  there  may  be  a 
conflict  over  sharing  the  best  people  between  the  two  efforts.) 

The  Group  put  together  an  initial  list  of  short  term  products  we  wanted  from  the  prototype  effort 
to  aid  in  defining/scoping  the  effort.  The  list  helped  us  get  going  by  making  the  products  and 
scope  of  effort  more  concrete.  From  this  list,  we  went  to  a  draft  schedule  and  then  to  the  list  of 
the  five  functions  of  the  PIRR  that  are  described  later: 

1 .  M&S  FDAd  procedures  and  policy  support 

2.  Database  design 

3.  Database  support  system:  Administration/reports 

4.  Tool  meta-products 
Translators/uses 

Export  and  Import  with  semantics  and  cost 

5.  TAFIM/TRM  compliant  platform  system  for  PIRR 

6.  8320.1.M.1  status  tracking  and  support  to  meet  shortcomings  identified  for  the  DDRS 
(e.g.,  should  this  be  the  shortcomings  we  have  identified  or  only  those  we  will  address  in 
the  short  term?  Should  we  state  which  the  PIRR  will  correct?) 

Application  Engineering  Process  to  get  to  IRR  Prototype: 

Functional— >  Requirements  — >  Design— >  Implementation-^  Test  - > 

Analysis  Analysis . 


94  AUG??  95  JAN  1  95NOV1 

Initial  Functional  Analysis: 

On  August  17th,  we  spent  some  time  defining  the  initial  functional  requirements  for  the 
Prototype  IRR  (PIRR).  They  are: 

1 .  Tracking  of  data  models,  complex  data  models,  and  data  standards 
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2.  Storage,  reporting  and  maintenance  of  data  models,  complex  data  models,  and  data 
standards 

3.  Support  for  multiple,  simultaneous  users  of  the  PIRR 

4.  DDRS  package  submittal  and  tracking 

5.  Access  to  DDRS  information 

It  is  recommended  that  additional  work  on  defining  functions  be  done:  by  using  the  MITRE 
IDEFO  process  models  for  the  FDAd,  DAd,  and  organization  submitting  data  models  and 
standards  as  soon  as  these  are  completed  (MITRE)  will  be  aided  by  Linda  Calvert  in  tins 
activity);  and  through  discussions  with  Chien  Huo,  8320  guidance,  and  Chien  s  view  of  his 
policies  and  procedures  in  terms  of  carrying  out  the  8320  guidance. 


Requirements  Analysis:  _  ,  ,  ,  ,  _  . 

1  Begin  with  output  of  functional  analysis,  including  IDEFO  models  that  define  the  concept 
of  operation  for  how  the  M&S  FDAd  will  operate,  the  M&S  data  administrator  will 
operate,  and  the  M&S  organization  submitting  standards  will  operate. 

2  Develop  alternatives  to  satisfying  functional  requirements  and  discuss  trade  offs  in  terms 
of  satisfying  the  PIRR  and  long  term  IRR  goals:  TAFIM/TRM  conformance,  reuse  of 
existing  software.  One  of  the  alternatives  to  evaluate  can  be  the  DDRS. 

3.  End  result  is  to  define  and  document  choice  of:  platform  and  development  environment, 
objects,  tools  and  standards. 

—  Draft  System  Requirements  document:  15  NOV  94 
—  System  Development  Plan:  1  JAN  95 


Design,  Implementation,  and  Test: 

Accurate  planning  for  the  design,  implementation  and  test  phases  are  dependent  on  the 
development  environment.  All  effort  should  be  made  to  reuse  available  software  tools  and  do  as 
little  original  implementation  as  possible.  Mike  Gorman  suggested  seriously  looking  at  use  of 
Oracle  and  the  Oracle  CASE  tools  to  accomplish  this. 


Availability  of  staff  and  Level  of  Effort: 

Level  of  effort:  The  group  estimated  24  technical  months  of  effort  are  required  to  perform  the 
PIRR  requirements  analysis.  It  should  begin  no  later  than  1  September  94  to  meet  the  1  Jan.  96 
delivery. 

Availability  of  staff  (assuming  DMSO  pays  for  them): 

Luci  Haddad  (RCI  support  of  CCTT,  Orlando  FL)  could  participate  fully 

Eleanor  Schroeder  (NAVOCEANO,  Miss.)  will  check  ability  to  participate  equivalent  of  two 
months 

Tony  Rhodes  and  Lori  Lindholm  (UTSS  program  support,  Washington)  would  be  available 
fulltime 

Peter  Valentine  (JDBE,  Ft  Huachuca)  would  be  available  1/3  time 

Linda  Calvert,  Steve  Miller,  Ron  Farkas  (SRA,  Washington)  would  be  available  fulltime. 

T  .inda  would  be  available  to  run  the  effort 

Jim  Augins  (support  for  ARMS,  San  Diego)  would  be  available  1/2  time 
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Mike  Dabose  (support  for  ARMS)  offered  to  run  the  effort  on  a  parttime  basis  because  he 
realizes  the  importance  of  it 

We  thought  at  least  three  face-to-face  meetings  would  be  needed.  Since  at  least  the  SRA  and 
UTSS  people  are  in  the  Washington  area,  Iris  suggested  it  might  be  desirable  to  center  the  project 
there  with  additional  support  from  Augins,  Valentine,  Haddad,  and  Schroeder  (since  they  all 
bring  unique  expertise  to  the  effort).  In  addition,  we  should  consider  Mike  Dabose's  offer  to  run 
the  project  since  he  is  government.  Both  Dabose  and  Calvert  have  had  experience  running 
projects. 
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8.5  ACTION  ITEMS 


ISSUCS! 

1 .  Linda  Calvert  will  coordinate  with  Chien  Huo  Wednesday  afternoon  on  the  outcome  of 
this  meeting  and  by  August  22-23  there  should  be  an  identified  focal  point  for  the  PIRR 

effort.  . 

2.  Name  of  system:  Architecture  vs  system  vs  facility  vs  requirement  or?  Group  agreed  on 
calling  it  the  M&S  Information  Resources  Repository,  either  MSIRR  or  M&S  IRR. 

Chien  Huo  should  make  decision. 

3.  Repository  taxonomy 

a.  platform  (components) 

b.  objects 

c.  tools 

d.  applications  .  , 

Group  needs  to  extend  this  and  to  organize  it  into  a  better  taxonomy  (see  Valentine  s 

initial  attempt  in  Appendix  C)  ,  ,in 

4.  Repository  group:  Address  audit  trail  and  tagging  data  and  work  with  Data  VV&C  TF  on 

these  issues 
People  Assignments: 


Jim  Aiigins 

1.  With  Valentine  continue  to  identify  different  file  formats  toward  deciding  on  defacto 
formats  for  exchanging  different  types  of  objects  within  group 

2.  Send  Valentine  information  on  data  modeling  tools  being  used 


Linda  Calvert 

1.  If  the  PIRR  effort  is  supported  by  DMSO,  then  the  timeline  needs  to  be  put  into  the 

DASP  .  ,  ,  . 

2.  Changes  to  activity  lists  for  FDAd  needs  to  be  sent  to  Mike  Gorman  by  close  of  business 

August  24, 1994 


Mike  Gorman 

1 .  Work  with  Valentine  on  deficiencies  of  DDRS  asap 

2.  MITRE  develop  IDEFO  processes  for  M&S  FDAd,  DAd,  and  M&S  organization 
submitting  standards  to  the  M&S  FDAd  (Linda  Calvert  will  help).  For  FDAd 
functionality  and  possible  reuse,  review: 

a.  DDRS 

b.  Army  standards  process  application  at  AMSMO,  contact  Lana  McGlynn  703-607- 
3384 

c.  Army  Standards  process,  contact  Jim  Glymph  703-806-3858 

d.  Navy  standards  process  contact  Gregg  Michaels  703-506-581 1  and  Rebecca  Wade 
(Navy  CD  Ad 

3.  Prepare  written  standards  update  to  include: 

—  Data  Management  Services  (SQL,  IRDS,  PCTE,  ATIS,  Object,  data  element 
standards) 

—  Software  Engineering  Services  (CASE  Tools  and  Environments,  Software 
Engineering  Environment) 

—  User  Application  Interface  (API,  TAFIM  HCI,  NIST  API), 

—  Distributed  Computing  (DCE) 

—  Data  modeling  (IDEF IX) 

—  Process  modeling  (IDEFO) 

_ Platform  standards  consistent  with  TAFIM/TRM 
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—  Tailoring  of  document  standards  for  development 
—  490  Standards:  See  UTSS  and  software  standards 

4.  Comparison  between  Oracle  and  Sybase  RDBMSs  especially  with  respect  to  software 
generation 

5.  Submit  the  current  E-R  diagram  and  definitions  as-is,  don't  do  any  more  work  on  them 

6.  Get  together  descriptions  of  data  and  object  oriented  groups  and  standards 

7.  Arrange  for  Len  Gallagher  to  talk  to  group  about  objects  as  used  in  SQL3  (e.g.,  how  is 
part-whole  addressed) 

8.  Will  make  copy  of  SQL3  available  to  group  (on  disk,  -1800  pages) 

Chien  Huo 

1 .  Decision  on  name  for  repository  system.  Repository  group  recommends  M&S 
Information  Resources  Repository  (either  MSIRR  or  IRR) 

2.  Redirect  MITRE  to  do  items  listed  above  rather  than  continuing  on  current  course 

3.  Give  CONOPS  for  M&S  FDAd  draft  dated  8/12/94  to  Mike  Gorman 

Luci  Haddad 

1 .  Send  Valentine  info,  on  data  modeling  tools  being  used 

2.  Send  survey  to  Group  on  software  reuse  repositories  especially  those  built  and  used  by 
Defense 

3.  Send  Mike  Gorman  the  IDEFO  process  model  CCTT  did  for  8320.1-M-l  process 

Iris  Kameny 

1 .  Work  to  complete  list  of  IRR  tools,  others  should  send  input  to  Iris 

2.  Get  notes  of  this  meeting  prepared  asap  and  mailed  to  others 

3.  Send  Mike  Gorman  copy  of  DCE  document  received  from  CECOM 

Jim  Santangelo 

1 .  Send  copies  of  UTSS  Requirements  document  and  other  relevant  documents  to  attendees 

2.  UTSS  will  be  developing  and  evaluating  alternatives  for  their  repository  selection,  all  of 
this  information  needs  to  be  shared  with  the  repository  group  and  the  PIRR  requirements 
effort 

Peter  Valentine 

1 .  POC  for  collecting  data  modeling  tools  information  (especially  from  Haddad  and  Augins) 

2.  With  Augins  continue  to  identify  different  file  formats  toward  deciding  on  defacto 
formats  for  exchanging  different  types  of  objects  within  group 

3.  Work  with  Gorman  on  deficiencies  of  DDRS  asap 
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8.6  MEETING  BRIEFS/DISCUSSIONS 

8.6.1  OPENING  DISCUSSION  ON  OBJECTS  AND  STANDARDS:  MOSTLY  MIKE 
GORMAN 

The  meeting  began  with  a  discussion  of  standards  especially  object-oriented  standards,  with  the 
group  deciding  they  didn't  know  what  the  various  object-oriented  standards  groups  were  or  how 
their  missions  differed. 

The  following  information  was  supplied  by  Jim  Augins  by  email  after  the  meeting: 

ODMG:  Object  Data  Management  Group  is  a  consortium  of  ODBMS  vendors  broadly 
analogous  to  its  relational  counterpart,  the  SQL/Open  consortium.  This  group  published 
the  ODMG-93  standard  for  ODBMS  and  agreed  to  implement  it  in  18  months.  This 
group  is  not  part  of  OMG. 

ODBC:  Open  Database  Connectivity  is  Microsoft's  open  interface  for  accessing  data  in  a 
heterogeneous  environment  of  relational  and  nonrelational  database  management 
systems.  ODBC  is  vendor  neutral  and  is  "middleware."  It  allows  a  client  to  access 
DBMS  servers  without  having  that  server  vendor's  client  software.  It  allows  the  software 
developer  to  develop  an  interface  to  a  ODBC  module  that  can  talk  to  COTS  drivers  for 
multiple  DBMS  vendor's  servers.  It  is  becoming  a  defacto  standard  and  is  becoming 
increasingly  available  for  Unix  platforms. 

perl  and  DBperl:  Perl  is  an  interpreted  language  with  powerful  string,  scalar,  and  array 
processing  features  developed  by  Larry  Wall  that  "nicely  bridges  the  functionality  gap 
between  sh  (1)  and  C."  Since  relational  DB  operations  are  typically  textually  oriented, 
perl  is  particularly  well-suited  to  manage  the  data  flows.  The  C  source  code,  which  is 
available  free  of  charge  and  runs  on  many  platforms,  contains  a  user-defined  function 
entry  point  that  permits  a  developer  to  extend  the  basic  function  set  of  the  language.  The 
DBperl  Group  seeks  to  exploit  this  capability  by  creating  a  standardized  set  of  perl 
function  extensions  (e.g.  db_fetch(),  db_attach())  based  on  the  SQL  model  for 
manipulating  a  relational  DB,  thus  providing  a  portable  perl  interface  to  a  variety  of 
popular  RDMS  engines,  including  Sybase,  Oracle,  Ingres,  Informix,  and  Interbase.  In 
theory,  any  DB  engine  that  implements  a  dynamic  SQL  interpreter  in  its  HLI  can  be 
bolted  onto  the  perl  front  end  with  predictable  results,  although  at  this  time  backends 
exist  only  for  the  aforementioned  five  DB  engines. 

(More  information  about  perl  and  DBperl  can  be  found  in  Appendix  D). 
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Mike  Gorman  outlined  the  languages  and  object  oriented  standards  groups  as  shown 
below: 

STANDARDS  PURPOSE/DESCRIPTION 

GROUP 

ANSI/ISO  Object  Groups 

X3H2  DB  languages  committee;  includes  defining  all  interfaces  to 

persistent  data  (including  objects).  Sometimes  referred  to  as  the 
SQL  Committee.  By  1994  expect  single  valued  columns,  by  1997 
ADTs  within  a  column  (methods).  The  Federal  Govt  is  not 
participating  in  defining  this  standard  except  for  NIST.  Expect  to 
find  products  utilizing  SQL3  by  2001-2002.  There  should  be  a 
Call  Level  Interface  CLI/SQL2  1996  standard  to  support  the  API 
concept.  One  person  from  Microsoft  is  in  charge  of  developing  the 
CLI  standard. 

Coordinating  all  object-oriented  language  development  with  ANSI 
committees 
COBOL 
Fortran 
Pascal 
C 

C++ 

NON  ANSI/ISO  OBJECT  GROUPS 

OMG  Object  Management  Group:  CORBA  (Common  Object  Request 

Broker  Agent) 

SQL/ACCESS 

ODBC  Object  Database  consortium  originally  developed  by  Microsoft  and 

now  incorporated  in  PC  calls 

DCE  Distributed  Computer  Environment,  Remote  Data  Access  standard. 

Private  organization  of  vendors. 

8.6.2  REPOSITORY  DATA  INFORMATION  MODELING  DATA:  PETER 
VALENTINE 

Peter's  brief  is  attached  in  Appendix  A  along  with  additions  agreed  to  by  group. 

Peter  began  by  saying  there  are  two  kinds  of  repositories:  (1)  those  storing  metadata  and  (2) 
warehouses  for  instance  data.  The  Group  preferred  thinking  in  terms  of  two  types  of  data: 
Metadata  and  instance  data  since  a  warehouse  repository  may  also  have  metadata  about  the 
warehouse  data.  It  is  difficult  to  come  up  with  a  good  definition  of  metadata  as  distinct  from 
instance  data.  The  IEEE  Metadata  WG  has  been  having  a  hard  time  going  so  as  has  everyone 
else— so  the  group  did  not  waste  much  time  on  this. 

We  had  some  discussion  of  the  CDIF  PCTE  repository  standard.  Linda  Calvert  handed  out  a 
paper  on  it  and  said  that  Steven  Miller  at  RSA  would  call  Peter  to  give  him  more  information. 
Linda's  thought  was  that  the  repository  group  might  be  able  to  leverage  the  CDIF  subject  areas  in 
deciding  on  the  taxonomy  for  the  repository. 


X3H7 

X3J4 

X3J3 

X3J9 

X3?? 

X3?? 
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Some  additional  notes  on  Peter's  brief: 

INQUISIX:  for  taxonomies  for  domain  analysis  was  developed  by  Software  Productivity 
Solutions  in  Melbourne  Florida;  they  have  a  contract  with  Rome  Labs 

DoD  reuse  repositories:  ASSETS  and  CARDS  were  both  ARPA  funded  developments  and  could 
be  used  as  repositories  for  data,  algorithms  and  M&S.  But  it  was  pointed  out  that  these 
repositories  manage  their  assets  at  an  object  or  container  level.  They  are  not  able  to  get  inside 
the  object  or  container  and  access  components.  The  Defense  Software  Reuse  System  (DSRS)  is 
another  reuse  repository  as  is  the  Army  reuse  repository.  There  may  be  some  lessons  to  be 
learned  and  to  be  borrowed  from  these  efforts  since  the  M&S  IRR  includes  software  reuse.  Luci 
Haddad  suggested  taking  a  good  look  at  these  and  she  will  gather  information  and  review  these 
for  the  group. 

Security  Issues: 

—  Poly-instantiated  data:  copies  of  the  same  data  item  may  be  labeled  at  different  security 
levels.  Several  reasons:  (1)  could  be  due  to  differences  in  security  labeling  by  different 
services,  and  (2)  there  are  real  examples  where  the  source  causes  the  security  label  to 
change  (for  example  the  same  data  item  may  have  the  same  value  but  different  security 
levels  depending  on  whether  the  value  came  from  the  Intel  community  or  from  an  open 
source  such  as  Janes). 

—  We  also  need  to  consider  security  issues  with  respect  to  classification  of  metadata. 

—  Another  security  issue  has  to  do  with  releasability  of  metadata  and  instance  data.  In  fact 
this  isn't  restricted  to  classified  data,  an  example  was  given  at  the  last  I/DB  by  BMDO 
about  it  taking  over  a  year  now  for  BMDO  to  try  to  release  unclassified  data  to  NASA 

—  The  Data  W&C  TF  is  addressing  audit  trail  and  tags  but  the  repository  group  also  needs 
to  address  these  issues  and  work  with  the  Data  VV&C  TF  on  these  issues. 

Data  modeling  tools:  the  DDRS  is  on  an  AT&T  machine  and  the  Defense  Interim  data 
repository  is  hosted  on  a  VAX.  Linda  Calvert  kept  bringing  up  the  issue  that  for  the  M&S  FDAd 
initial  repository,  we  may  create  a  political  problem  in  NOT  USING  the  DDRS.  We  need  to 
consider  the  DDRS  as  an  alternative  solution  in  our  evaluation  and  come  up  with  substantial 
reasons  if  we  decide  not  to  use  it. 

File  formats:  the  idea  of  the  file  formats  is  to  come  up  with  a  set  of  formats  to  use  in  order  to 
exchange  information  among  the  Group  members. 

8.6.3  M&S  DISTRIBUTED  INFORMATION  RESOURCES  REPOSITORY  (IRR) 
TAXONOMY:  IRIS  KAMENY 

Iris  Kameny  put  together  a  two  page  list  of  four  areas  that  need  to  be  addressed  for  the  IRR. 

They  are:  open  systems  platform,  objects  to  be  managed,  tools  and  applications.  She  also 
showed  five  example  types  of  M&S  IRRs  and  what  she  would  expect  to  be  found  in  each  of  the 
repositories:  (1)  repository  for  use  by  the  M&S  FDAd,  (2)  data  warehouse  or  data  center 
repository,  (3)  M&S  software  reuse  repository,  (4)  M&S  study  director/DIS  exercise  director 
repository,  and  (5)  M&S  developer  repository.  The  ordering  is  her  interpretation  of  the 
importance  of  providing  the  type  of  repository  to  the  M&S  community.  Her  purpose  in  doing 
this  was  her  view  that  the  MITRE  document  has  concentrated  solely  on  (5)  the  M&S  developer 
and  perhaps  they  still  did  not  understand  that  the  M&S  I/DB  main  purpose  is  to  support  the  M&S 
area  with  correct,  valid,  timely,  etc.  data  for  the  other  usages. 
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The  two  page  listing  is  in  Appendix  B.  Peter  Valentine's  reorganized  taxonomy  of  it  is  in 
Appendix  C.  The  "objects  to  be  managed"  section  provided  a  good  framework  for  much  of  the 
discussion  during  the  remainder  of  the  meeting. 

8.6.4  DISCUSSION  OF  MITRE  TASK  PRODUCTS:  MIKE  GORMAN 

The  Repository  Subgroup  had  several  comments  to  make  about  the  MURE  draft  document 
"Modelling  and  Simulation  Repository  Facility"  dated  12  August  1994: 

1.  There  was  an  objection  to  the  name  "Modelling  and  Simulation  Repository  Facility" 
which  was  described  in  the  issues  section  of  these  notes 

2.  The  main  body  was  presented  in  chart  format  (without  annotations)  and  there  were 
discussions  about  several  of  the  charts  as  being  incorrect,  missing  the  point,  misleading, 
etc.  These  include: 

a.  The  chart  of  the  repository  metamodels  and  M&S,  repository  data  and  repository 
directory:  this  probably  captures  the  best  example  of  omission  and  misunderstanding 
since  it  doesn't  even  mention  data  standards  or  the  data  standardization  process,  etc. 

b.  The  chart  showing  the  M&S  repository  community  network  with  DMSO  at  the  center 
was  judged  misleading  unless  it  was  stated  that  this  was  a  view  of  relationships  for 
entering  M&S  data  standards.  Other  points  were  that  there  can  be  multiple 
repositories  in  each  service,  and  the  service  repositories  can  talk  to  each  other  directly 
across  services  (don't  have  to  go  through  DMSO). 

c.  The  next  chart  with  DIRS  at  the  center  should  have  DDRS  at  the  center  and  should 
refer  to  other  functional  areas  as  "functional  areas"  such  as  C2  and  Intelligence 

The  discussion  went  from  there  to  the  IDEF1X  diagram  which  confused  the  group  because  it 
seems  to  be  (and  Mike  Gorman  agreed)  a  data  model  of  an  M&S  Directory.  This  was  not  a 
project  deliverable  since  we  already  have  a  data  model  of  the  M&S  Directory  agreed  to  by  the 
community  and  a  copy  of  that  and  the  Database  Directory  data  model  were  given  to  MURE  a 
number  of  months  ago.  Gorman  then  said  that  the  data  model  could  be  interpreted  as  a  two  step 
removed  more  detailed  model  of  the  objects  listed  in  Appendix  B  but  most  of  the  group  had  a 
problem  understanding  this  explanation. 

The  main  problem  with  the  MURE  effort  was  that  somehow  they  had  gotten  diverted  from 
serving  the  goal  of  the  data  suppliers  and  supporters  to  M&S  and  had  instead  concentrated  on 
Modeling  and  Simulation.  So  there  is  no  mention  of  the  most  important  objects  that  need  to  be 
managed  by  the  prototype  repository  for  the  M&S  FDAd  nor  of  the  relationships  of  those  objects 
to  each  other  and  to  the  tools  that  might  reside  in  the  repository. 

The  Repository  Subgroups  recommendation  is,  given  the  limited  time  remaining  for  the  MURE 
task,  that  they  concentrate  on  those  well  defined  tasks  enumerated  under  Mike  Gorman's  name  in 
ACTION  ITEMS. 

8.6.5  TECHNICAL  ARCHITECTURE  FRAMEWORK  FOR  INFORMATION 
MANAGEMENT  (TAFIM):  KEN  KAUFMAN 

This  brief  was  to  discuss  the  TAFIM,  Navy  use  of  the  TAFIM,  and  some  problems.  The  briefing 
addresses  a  particular  Navy  architecture  problem  for  the  Data  Link  Processing  and  Control 
System  (DLPCS)  Goal  Architecture  which  needs  to  support  reliable  multicasting. 

The  TAFIM  and  the  Technical  Reference  Model  (TRM)  which  is  part  of  the  TAFIM  calls  for  use 
of  open  systems  and  COTS  products.  Its  purpose  is  to  provide  vendor  independent  choice  of 
products  and  reduce  life  cycle  costs  of  DoD  projects. 
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The  TAFIM  provides  a  framework  for  Life  Cycle  Development  and  for  levels  of  integration 
(DoD,  mission,  function,  application  and  personal).  It  provides  for  simultaneous  integration 
processes  that  will  provide  a  best  of  breed  solution  and  for  different  views  of  a  model.  This  brief 
presents  a  top-down  view  of  the  DLPCS  goal  as  TAFIM  compliant  and  an  evolutionary  view 
(bottom-up)  of  C2P  and  LEDS.  The  reality  will  be  something  between  the  two  based  on  cost, 
user  needs  and  time  constraints. 

Ken  showed  that  the  two  views  would  result  in  a  final  product  that  would  meet  the  TAFIM 
within  reasonable  technical  and  programmatic  integration  constraints.  The  initial  focus  was 
largely  on  the  development  of  models  using  functional  areas  and  activity  perspectives  to  achieve 
the  TAFIM  goals.  This  reduced  the  need  to  develop  new  applications,  data  and  technical 
infrastructure.  As  the  bottom  up  view  is  developed,  new  cross-functional  integration  and 
interoperability  will  be  possible.  Future  implementations  would  be  possible  with  off-the-shelf 
applications  developed  by  other  TAFIM  programs.  Those  programs  also  benefit  from  the 
DLPCS  applications  being  available  for  integration  within  their  products.  He  was  concerned 
over  the  lack  of  a  requirement  for  an  API  between  the  mission  applications/architecture  and  the 
next  layer  down,  the  support  application  layer. 

8.6.6  SECURITY  OVER  INTERNET 

This  was  a  brief  by  Joan  McCaffrey  of  Me  Info.  (6219-942-4164)  about  a  3COM  Access  Builder 
remote  access  server  that  will  support  some  access  control  features  for  remote  users  using  dial-up 
connections  to  the  enterprise  network.  It  could  achieve  secure  communications  if  used  in 
conjunction  with  a  STU3  encryption  modem.  The  box  serves  as  a  router  for  IP  and  other 
network  systems.  Access  control  includes  password  protection,  automatic  callback,  logging  of 
unauthorized  attempts  and  reporting  of  those  to  a  management  station.  It  also  has  a  resource 
access  manager  that  insulates  individual  network  segments  running  mission-critical  applications. 
"In  addition,  special  security  software  can  interact  directly  with  network-based  security  servers 
and  security  software  located  on  client  nodes.  This  software  provides  a  standards-based  security 
model  that  supports  OSF/DCE  security  server  today,  and  will  be  compatible  with  a  broader  set  of 
security  systems  in  the  future."  (OSF/DCE  is  Open  Systems  Foundation/Distributed  Computing 
Environment)  The  router  can  dial  into  another  LAN  for  a  direct  LAN  to  LAN  connection. 

Instead  of  using  the  ports  for  single  interfaces,  it  can  use  them  all  for  inverse  multiplexing, 
thereby  increasing  the  communication  bandwidth. 

8.6.7  ARMS  DEMONSTRATION:  MIKESTANSEL 

The  ARMS  Demonstration  included  the  Oracle/SuperCard  GUI  proof  of  concept  V  1.6  and  the 
complete  4th  Dimension  repository  for  data  analysis  and  the  ARMS  Model  Interface  (AMI). 

AMI  currently  provides  ability  to  build  major  scenarios  within  hours  rather  than  weeks,  and 
automatically  loads  data  to  the  ITEM  model.  ARMS  Version  2.0  is  under  development.  High 
points  included: 

ARMS  2.0  will  be  Platform  independent!  Original  source  code  can  be  compiled  on  platform 
of  choice  (SUN,  HP  TAC  Ed,  Macintosh,  PC  Windows/OS2). 

ARMS  currently  contains  MOE's  in  addition  to  physical  characteristics  of  platforms  and 
systems. 

ARMS  V  2.0  will  provide  browsing  capability  to  other  databases  or  repositories. 

ARMS  V  2.0  will  support  Client/Server  architecture. 

Source  tagging  by  data  element  (Classification/Source/Date). 
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Multiple  sources  for  each  data  element. 

User  can  add  own  data  without  changing  core  data. 

Notes  can  be  attached  to  archive  of  a  scenario;  scenario  can  be  reloaded  to  the  model  at  a 
later  time  for  further  analysis  of  data  and  changing  of  sources. 

ARMS  provides  an  existing  system  capability  that  has  a  well  accepted,  logical  and  easy  to  use 
interface.  Its  structure  provides  a  means  to  see  data  associated  with  any  country,  identified  to 
branch  of  service  and  mission  areas.  The  structure  also  allows  users  to  see  data  for  each  element 
from  different  or  multiple  sources.  Data  for  joint  service  support  is  being  expanded  based  on  the 
needs  of  the  users. 

8.6.8  SIMULATION  AND  HUMAN  SYSTEMS  TECHNOLOGY  DIVISION:  KEVIN 
BONER 

This  work  is  being  done  for  ARPA  as  part  of  the  simulation  infrastructure  and  will  support 
STOW-E.  It  is  part  of  an  effort  to  link  constructive,  live  and  virtual  simulations.  The  future  DSI 
with  robust  multicasting  may  use  the  DIS  encapsulated  stream  protocol.  In  the  long  run,  DIS 
will  be  IP  compatible.  Industry  is  now  looking  at  streams  and  there  may  soon  be  a  commercial 
stream  standard  and  products  implementing  the  standard. 

Question  was  asked  about  how  to  supply  data  to  DIS  before  an  exercise.  The  suggestion  was  that 
DIS  nodes  had  an  IP  port  that  could  be  used  but  that  all  the  simulators  are  tied  to  the  stream  port. 
It  would  seem  that  data  to  be  used  in  an  exercise  would  be  sent  to  a  DIS  repository  managed  by 
the  exercise  developer  and  from  there  it  would  be  distributed  to  the  various  simulators.  The  way 
out-of-band  data  is  handled  in  STOW-E  (data  collected  during  the  exercise)  is  by  FTP  at  specific 
times  such  as  early  morning  and  late  at  night  when  it  will  not  interfere  with  the  exercise. 

The  briefing  showed  how  the  existing  BBS  network  is  interfaced  to  the  existing  SIMNET 
network,  how  the  first  phase  of  live  would  be  handled,  algorithms  for  supporting  large  numbers 
of  players  on  the  DSI,  the  DSI  Red  connection,  and  interconnecting  CMTC-IS  Hohenfels  and 
BBS  Hohenfels  and  Simnet  at  Grapenwoehr  for  STOW-E. 

8.6.9  UTSS  BRIEF:  JIM  SANTANGELO 

Jim  gave  us  an  update  on  UTSS  with  special  emphasis  on  products  they  have  produced  that 
might  be  of  help  to  the  Repository  Subgroup.  These  include: 

User  assessment 

Technology  Evaluation:  COTS  and  GOTS  hardware  and  software,  including  platforms  and 
DBMSs 

Cost  Constraints 

Policies  and  Procedures  Constraints  Report 
Preliminary  Concept  of  Operations 
Requirements  Analysis 

System  Engineering  Management  Plan  (SEMP) 

Systems  Engineering  Analysis  (includes  identifying  reusable  software) 

System  Specification  (in  progress) 

UTSS  will  share  their  documentation  and  lessons  learned  with  the  Repository  Subgroup. 
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8.6.10  FINAL  REMARKS:  JIM  AUGINS 

One  of  the  objectives  of  this  meeting  that  wasn't  addressed  was  how  to  interconnect  the  existing 
M&S  data  centers.  That  will  need  to  be  put  off  until  another  day. 
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8.7  APPENDICES 

APPENDIX  A:  REPOSITORY  DATA  INFORMATION  MODELING  DATA:  PETER 
VALENTINE 

Pete's  viewgraphs  have  been  repeated  below  with  changes/additions/notes  made  during  the 
session. 


Repository  Data  Information  Modeling  Data 

•  Model  Characteristics 

— E/R  data  (entities,  attributes,  relationships,  cardinality,  domains  and  category  clusters) 
— Vendor  value-added  data  (rules,  defaults,  triggers,  declarative,  referential  integrity, 
etc.) 

•  Mappings 

— Inter/Intra  Model 
— 8320.X  standards 
— Physical  to  logical 

•  8320  Standards 

— Standard  data  element  naming 
— Proponency  and  responsibility 
— Submission  Cycle  and  Status 
— Security  (ADDED) 

— Releasability  (ADDED) 

Repository  Data  Instance  Data  Tagging 

•  Security 

— Multi-level-security  (MLS) 

— Security  tagging  (field,  row  (ADDED),  table  and  database  levels) 

— Multi-Service  regulation  conflicts  (Service  High?) 

— Poly-instantiated  databases 
— Downgrading  (ADDED) 

•  Audit  Trail  (ADDED:  ADDRESSED  BY  VV&C  TF  BUT  NEED  TO  CONSIDER  FOR 
REPOSITORY  ALSO) 

— Data  source 
— Modification  history 
— Registered  data  producers 

•  Tagging  formats 
— Bit-level  ANDs 

— Multiple,  modular  tagging  packages 

•  Releasability  (ADDED) 

•  Performance  (ADDED) 
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Communication  Protocols  for  use  by  the  Repository  Subgroup 

(Pete  asked  for  show  of  hands  as  to  which  Repository  Subgroup  attendees  had  which  capabilities, 
"client"  implies  the  person  has  the  service  available,  "server"  implies  the  person’s  organization 
can  act  as  a  server) 


PROTOCOL  #CLIENTS 

Internet  E-Mail  9 

CompuServe  E-Mail  2 

FTP  8 

Gopher  9 

World-Wide- Web  8 

Dial-Up  Bulletin  Board  5 

Telnet  8 


perlDB  (access  to  DB  over) 
Internet  (ADDED) 


#SERVERS 

1 

1 

3 

4 
1 
1 


Data  Modeling  Tools 

(reflects  what  tools  the  M&S  data  modeling  community  is  using)  (ADDED) 

(all  words  on  righthand  side  of  colon  were  added  by  note  taker): 

•  ER/WIN  (ERX  and  DBF):  blessed  by  M&S  FDAd 

•  BF/WIN  (ADDED) 

•  Leverage:  used  in  DoD  Interim  repository 

•  IE  Advantage:  being  used  by  CIM 

•  WIZDOM:  IDEF1X  tool  being  used  by  CCTT 

•  KBSI:  T&E  community  is  using  it;  used  to  support  IDEF3  modeling  (process  modeling 
with  activation) 

•  System  Architect:  joint  Navy/AF  for  Air  Tasking  Order  (ADDED) 

•  Protosoft:  the  new  Naval  Simulation  System  (ADDED) 

•  Reuse  Library  Framework  (RLF)  used  for  taxonomy  modeling  (Unix  env)  (ADDED) 

•  INQUISIX:  used  for  taxonomy  modeling  (Unix  env.)  (ADDED) 

•  Sterling:  meta  model  capability  language  (ADDED) 

File  Formats 

(We  agreed  this  could  be  of  indeterminable  length  and  needs  to  be  restricted  to 
those  we  might  be  interested  in  using  to  exchange  repository  information) 

ER1  ER/WIN  native  format 

ERX  ER/WIN  ASCH  Export  format 

DDL  Data  definition  language  (SQL) 

TXT  ASCB  text  file  (MS-DOS) 

ASC  ASCB  text  file  (Unix) 

SML  Structured  Modeling  Language 

DOC  MS-Word  (Windows) 

RTF  Rich  Text  Format  (ASCII  exchange  format) 

PS  Post-Script  document 

EPS  Encapsulated  Post-Script  (single  graphic) 

ZIP  ZIP  Compression  format 

Z  Unix  compression 

ARC  ARC  compression 

HQX  MAC?? 

WP5  Word  Perfect  5.x  document 

DBF  dBase  File  (version  3  or  4) 
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Note:  Need  to  compile  a  database  of  file  formats  and  viewers 

DDRS  Insufficiencies 

•  Cannot  address  complex  data  used  by  DoD  acceleration  guidance 

•  Requires  mandatory  data  not  available  to  end  users  (EXPLANATION:  SOME 
MANDATORY  METADATA  CONSISTS  OF  CODES  TO  BE  FILLED  IN  BY  FDADS) 

•  Not  widely  or  easily  available  to  majority  of  DoD 

•  Cannot  store  data  models  and  is  not  model  based 

•  Data  elements  are  not  mapped  to  data  models,  no  integrity  enforcement 

•  No  export  facility  -  users  cannot  review  data  off-line 

•  Documentation  out-of-date  with  current  tool 

•  User  interface  is  user-hostile  and  slow 

Additional  from  discussion: 

•  No  directory  to  instance  databases 

•  No  link  to  DSRS 

•  No  usage  metadata 

•  Data  elements  have  been  entered  without  being  modeled  in  a  data  model 

•  Doesn't  capture  business  rules 
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APPENDIX  B:  M&S  INFORMATION  RESOURCES  REPOSITORY  (IRR)  LIST:  IRIS 
KAMENY 

Note  that  this  was  a  quick  dump  of  the  types  of  things  to  consider  in  developing  a  repository: 
platform,  objects,  tools  to  manage  and  use  objects  and  repository,  applrcatrons  to  utrlrze  objects 
and  tools.  More  work  is  needed  by  the  Repository  Subgroup  to  flush  these  out  and  to  better 
organize  them.  The  "Y"  and  "O"  are  not  meant  to  be  definitive  but  representative,  any  repository 
could  contain  all  of  the  items  and  serve  multiple  uses. 

Where: 

(1)  M&S  FDAd 

(2)  Data  Warehouse/Center 

(3)  M&S  Reuse  Repository 

(4)  Study  Director/DIS  Exercise  Director  Repository 

(5)  M&S  Developer  Repository 

And: 

Y  =  yes 
O  =  optional 

blank  =  don't  know  or  not  applicable 


A.  OPEN  SYSTEMS  PLATFORM 

mm\ 

1. 

Hardware  (e.g.,  HP,  Sun) 

Y 

Y 

Y 

Y 

Y 

2. 

Operating  System  (e.g.,  Unix,  Posix) 

Y 

Y 

Y  | 

Y 

Y 

3. 

DBMS  (e.g.,  relational,  object-oriented)  1 

Y 

Y 

O 

Y 

0 

4. 

Human  Computer  Interface 

Y 

Y 

Y 

Y 

Y 

B.  OB 

JECTS  TO  BE  MANAGED 

Ml 

| 

1. 

IRR  directory 

KM 

S 

Y 

O 

Y 

0 

2. 

Process  models  (IDEFO) 

3. 

Data  models  (IDEF1X) 

Y 

Y  i 

o 

4. 

Complex  data  models 

Y 

Y 

6 

5. 

Data  standards/  data  dictionary  (e.g.,  DDRS) 

Y 

Y 

Y 

6: 

Domain/nomenclature,  symbology  standards 

Y 

Y 

Y 

7. 

M&S  directory 

Y 

8. 

Database  directory 

Y 

9. 

Instance  database(s) 

Y 

o 

Y  ! 

0 

10. 

Instance  database(s)  schemas  and  dictionary 

Y 

Y 

11. 

Mapping  from  instance  DB  schema  to  data  standards 

Y 

Y 

12. 

Database  Quality  Profile  (data  VV&C) 

Y 

Y 

13. 

Standard  algorithms 

O 

Y 

Y 

Y 

14. 

Model  and  Simulation  software 

Y 

Y 

Y 

15. 

M&S  VV&A  documentation 

Y 

Y 

Y 

16. 

Authoritative  Data  Sources  directory 

Y 

C.  TC 

>OLS 

1. 

Directory  tools  (i.e.,  IRR,  database,  M&S  Authoritative 
Data  Sources) 

■I 

| 

2. 

IDEFO  tool 

Y 

O 

O 

o 

3. 

IDEF1X  tool 

Y 

Y 

Complex  data  modeling  tool(s) _ _ 


■y  tools  _ 


6.1  API  for  DBMS  _ 

Mapping  tool/manipulation  of  DB  schema 


9.  |  M&S  VV&A  process  tool _ 

Tool  to  support  reverse  engineerin 


Tool  to  support  data  standardization _ _ 

Tool  to  link  1DEF0.  1DLF1X  and  data  standards 


Data  acquisition  tool  _ _ 


Data  post  processing  tool(s) 


D.  APPLICATIONS 

- 1  I  Snnnnrt  for  M&S  FDAd  data  standards  process 
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APPENDIX  C:  REPOSITORY  OBJECT  TAXONOMY:  PETER  VALENTINE 


Instance  Data  Sets,  these  data  sets  would  share  a  common  need  for  configuration 
management  to  include  versioning,  audit  trail,  etc. 

A.  Automated  Data 

1.  Relational  Databases 

Any  data  stored  in  relational  database  tables  (easily  imported  into  a  repository 

2.  File  Structures 

Complex  record  data  structure  (which  would  need  storage  as  Blobs) 

3.  Non-Relational  DBMS 

Data  stored  in  Hierarchical,  Network,  or  Object  databases 

B.  Electronic  Documentation 

Compound  documents  (could  contain  graphics,  etc.)  which  are  stored  and  cataloged 
to  permit  retrieval  by  users  of  the  repository 

1.  Standards  documents 

Compound  documents  cataloged  and  stored  for  use  by  M&S  community 

2.  System  documentation 

Compound  documents  which  describe  legacy/existing  systems  (data  providers) 

C.  Non- Automated  Data 

Hardcopy  or  physical  records  (maps,  books,  etc.) 

II.  Metadata  Information  about  the  data 

A.  Information  Modeling  Data 

1.  IDEF1X  models 
ERWin  models  initially 

2.  IDEFO  models 
BPWin  models  initially 

3.  Other  models 

Other  modeling  techniques  to  address  complex  data 

B.  Data  Elements  _ 

The  data  required  to  submit  and  track  submissions  to  the  DDRS 

C.  Domain/Nomenclature  Standards 

A  set  of  standard  domains  and  domain  values  (nomenclature) 

D.  Directory  Information  ....  , 

Directory/catalog  information  about  what  is  contained  within  the  repository  and 

pointers  to  external  objects  as  well. 

1.  Database  Directory 

2.  M&S  Directory 

3.  Authoritative  Source  Directory 

4.  IRR  Directory 

E.  Data  Quality  Profile 
***Need  definition 

F.  VV&A  Documentation 
***  Need  definition 
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G.  Mappings 

1.  From  schemas  to  models 

Tying  existing  physical  databases  and  schemas  within  the  repository  to  models 

2.  From  models  to  standards 

Tying  models  to  standard  data  elements 

H.  Instance  data  tagging 

1 .  Security  Level 

Tagging  of  instance  data  at  the  database,  table,  row,  and  field  level 

2.  Releasability 

Release  authority  and  POC  information 

I.  Audit  Trail  Tagging 

1.  Data  source 

Identify  the  source  of  the  data,  possibly  using  registered  producer  IDs 

2.  Modification  history 

Retaining  modifications,  and  timestamps  of  changes  to  the  data 
III.  Software 

A.  Standard  algorithms 

Standard  reusable  algorithms  which  are  commonly  used  by  the  M&S  community  (or 
the  M&S  data  community)  (possibly  using  some  kind  of  formal  pseudocode?) 

B.  Source  code 

Reusable  code  segments  and  complete  software  systems,  object  code? 
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APPENDIX  D:  PERL  AND  DBPERL:  MATERIAL  FURNISHED  BY  JIM  AUGINS 

MANY  DATABASE-ORIENTED  EXTENSIONS  TO  PERL  HAVE  BEEN  WRITTEN. 
SaSICMXY  THESE USE  THE  USUB  MECHANISM  (SEE  THE  USUB/  SUBDIRECTORY) 
SScFdIST^UTION)  TO  LINK  IN  a  DATABASE  LffiRARY,  ALLOWING 
EMBEDDED  CALLS  TO  INFORMIX,  INGRES,  INTERBASE,  ORACLE  AND  SYBASE. 

HERE  ARE  THE  AUTHORS  OF  THE  VARIOUS  EXTENSIONS: 


WHAT 

7INFOPERL 

INGPERL 

INTERPERL 

ISQLPERL 

ORAPERL 

PGPERL 

♦SQLPERL 

SYBPERL 

UNIPERL 


TARGET  DB 

INFORMIX 

INGRES 

INTERBASE 

INFORMIX 

ORACLE 

POSTGRES 

INGRES 

SYBASE 

UNIFY  5.0 


WHO 

KURT  ANDERSEN 
(KURT@HPSDID.SDD.HP.COM) 

TIM  BUNCE  (TIMBO@IG.CO.UK)  AND  TED 
LEMON 

BUZZ  MOSCHETTI  (BUZZ@BEAR.COM) 
WILLIAM  HAILS,  BILL@TARDIS.CO.UK 
KEVIN  STOCK  (KSTOCK@ENCORE.COM) 
IGOR  METZ  (METZ@IAM.UNIBE.CH) 

TED  LEMON  (MELLON@NCD.COM) 

MICHAEL  PEPPLER  (MPEPPLER  @  ITF  .CH) 
RICK  WARGO  (RICKERS@COE.DREXEL.EDU) 


?  Does  this  one  still  exist? 

*  Sqlperl  appears  to  have  been  subsumed  by  Ingperl 

Buzz  Moschetti*  has  organized  a  project  to  create  a  higher  level  interface  to  will  allow  you  to 
write  your  queries  in  a  database-independent  fashion.  If  this  type  of  project  interests  you,  sen 
mail  to  <perldb-interest-request  @  vix.com>  and  asked  to  be  placed  on  the  perldb-interest 
mailing  lists. 

Here's  a  bit  of  advertising  from  Buzz: 

Perl  is  an  interpreted  language  with  powerful  string,  scalar,  and  array  processing  features 
developed  by  Larry  Wall  that  "nicely  bridges  the  functionality  gap  between  sh  (1)  and  C. 
Since  relational  DB  operations  are  typically  textually  oriented,  perl  is  particularly  well-suited 
to  manage  the  data  flows.  The  C  source  code,  which  is  available  free  of  charge  and  runs  on 
many  platforms,  contains  a  user-defined  function  entry  point  that  permits  a  developer  to 
extend  the  basic  function  set  of  the  language.  The  DBperl  Group  seeks  to  exploit  this 
capability  by  creating  a  standardized  set  of  perl  function  extensions  (e.g.  db_fetch(), 
db  attachO)  based  the  SQL  model  for  manipulating  a  relational  DB,  thus  providing  a 
portable  perl  interface  to  a  variety  of  popular  RDMS  engines,  including  Sybase, oOT 
Ingres,  Informix,  and  Interbase.  In  theory,  any  DB  engine  that  implements  a  dyMmi  Q 
interpreter  in  its  HLI  can  be  bolted  onto  the  perl  front  end  with  predictable  results,  although 
at  this  time  backends  exist  only  for  the  aforementioned  five  DB  engines. 

The  official  archive  for  DBperl  extensions  is  ftp.demon.co.uk:  /pub/perl/db.  This  archive 
cont^nscopies  of  ports  forhigres,  Oracle,  Sybase,  Infomux  Unify,  Postgres,  and  Interbase,  as 
well  as  rdb  and  shql;  it's  the  home  of  the  evolving  DBperl  API  Specification. 
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There  are  also  a  number  of  non  SQL  database  interfaces  for  perl  available  from  ftp.demon.co.uk. 
These  include: 

Directory  Target  System  Authors  and  notes 

John  Conover  (john@johncon.com) 

John  Conover  Qohn@johncon.com) 

Eric  Douglas 

Walt  Hobbs  (hobbs@rand.org) 

Bruce  Momjian  (root@candle.uucp) 

1.1)  What  is  Perl? 

Perl  is  a  compiled  scripting  language  written  by  Larry  Wall*.  Here  s  the  beginning  of  the 
description  from  the  man  page:  Perl  is  an  interpreted  language  optimized  for  scanning 
arbitrary  text  files,  extracting  information  from  those  text  files,  and  printing  reports 
based  on  that  information.  It’s  also  a  good  language  for  many  system  management  tasks. 
The  language  is  intended  to  be  practical  (easy  to  use,  efficient,  coniplete)  rather  than 
beautiful  (tiny,  elegant,  minimal).  It  combines  (in  the  author's  opinion,  anyway)  some  of 
the  best  features  of  C,  sed,  awk,  and  sh,  so  people  familiar  with  those  languages  should 
have  little  difficulty  with  it.  (Language  historians  will  also  note  some  vestiges  of  csh, 
Pascal,  and  even  BASIC-PLUS).  Expression  syntax  corresponds  quite  closely  to  C 
expression  syntax.  Unlike  most  Unix  utilities,  perl  does  not  arbitrarily  limit  the  size  of 
your  data— if  you've  got  the  memory,  perl  can  slurp  in  your  whole  file  as  a  single  string. 
Recursion  is  of  unlimited  depth.  And  the  hash  tables  used  by  associative  arrays  grow  as 
necessary  to  prevent  degraded  performance.  Perl  uses  sophisticated  pattern  matching 
techniques  to  scan  large  amounts  of  data  very  quickly.  Although  optimized  for  scanning 
text,  perl  can  also  deal  with  binary  data,  and  can  make  dbm  files  look  like  associative 
arrays  (where  dbm  is  available).  Setuid  perl  scripts  are  safer  than  C  programs  through  a 
dataflow  tracing  mechanism  which  prevents  many  stupid  security  holes.  If  you  have  a 
problem  that  would  ordinarily  use  sed  or  awk  or  sh,  but  it  exceeds  their  capabilities  or 
must  run  a  little  faster,  and  you  don't  want  to  write  the  silly  thing  in  C,  then  perl  may  be 
for  you.  There  are  also  translators  to  turn  your  sed  and  awk  scripts  into  perl  scripts. 

OK,  enough  hype. 

1.2)  What's  the  difference  between  "perl"  and  "Perl?" 

32!  [  ord('p')  -  ord('P')  ]  (Shouldn't  that  be  42,  the  Answer  to  the  Great  Question  of  Life, 
the  Universe,  and  Everything?  ;) 

Larry  now  uses  "Perl"  to  signify  the  language  proper  and  "perl"  the  implementation  of  it, 
i.e.  the  current  interpreter.  Hence  Tom’s  quip  that  "Nothing  but  perl  can  parse  Perl. 

On  the  other  hand,  the  aesthetic  value  of  casewise  parallelism  in  "awk,"  "sed,"  and  "perl" 
as  much  require  the  lower-case  version  as  "C,"  "Pascal,;’  and  "Perl"  require  the  upper¬ 
case  version.  It's  also  easier  to  type  "Perl"  in  typeset  print  than  to  be  constantly  switching 
in  Courier. :-) 

In  other  words,  it  doesn't  matter  much,  especially  if  all  you're  doing  is  hearing  someone 
talk  about  the  language;  case  is  hard  to  distinguish  aurally. 


btreeperl  NDBM  extension 

ctreeperl  CTree  extension 

duaperl  X.500  DUA 

rdb  RDBMS 

shql  SQL  Engine 
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1 .3)  Has  perl  been  ported  to  machine  FOO? 

Perl  runs  on  virtually  all  Unix  machines  simply  by  following  the  hints  file  and 
instructions  in  the  Configure  script.  This  auto-configuration  script  allows  Perl  to  compile 
on  a  wide  variety  of  platforms  by  modifying  the  machine  specific  parts  of  the  code.  For 
most  Unix  systems,  no  porting  is  required.  Try  to  compile  Perl  on  your  machine.  If  you 
have  problems,  examine  the  README  file  carefully.  If  all  else  fails,  send  a  message  to 
comp.lang.perl  and  crosspost  to  comp.sys.[whatever],  there's  probably  someone  out  there 
that  has  already  solved  your  problem  and  will  be  able  to  help  you  out. 

Perl  has  been  ported  to  many  non-Unix  systems.  All  of  the  following  are  mirrored  at 
ftp.cis.ufl.edu:/pub/perl/src/[OS]/.  The  following  are  the  (known)  official  distribution 
points.  Please  contact  the  porters  directly  (when  possible)  in  case  of  questions  on  these 
ports.  All  I  do  is  archive  them,  I  don't  know  anything  about  them. 

*  MS-DOS  binaries  and  source  are  available  at  ftp.ee.umanitoba.edu  [130. 179.8.47]  in 
/pub/msdos/perl.  There  are  currently  half  a  dozen  different  ports  for  MS-DOS. 
BigPerl4  (v3)  is  perl4.036  compiled  with  the  Watcom  C/386  compiler  (32-bit,  flat- 
memory  model  C  compiler)  with  the  following  features: 

*  Up  to  32MB  of  memory  can  be  used. 

*  Supports  virtual  memory. 

*  Works  under  Windows  3. 1  (however,  a  second  copy  of  perl  cannot  be  spawned 
under  Windows). 

*  The  perl  debugger  can  be  used. 

*  Contains  GDBM  support. 

*  Windows/NT  binaries  are  available  from  ftp.cis.ufl.edu.  Does  anyone  know  the 
official  distribution  point?  I  got  these  from  archive.cis.ohio-state.edu  quite  awhile 
back. 

*  Macintosh  binaries  and  source  are  available  from  nic.switch.ch  [130.59.1.40]  in 
/software/mac/perl .  Version  4.1.3  is  perl4.036  compiled  with  the  MPW  C  compiler 

*  Mac_Perl_413_src.sit.bin  Sources 

*  Mac_Perl_413_tool.sit.bin  MPW  Tool 

*  Mac_Perl_413_appl.sit.bin  Standalone  Application 

There  is  a  mailing  list  for  discussing  Macintosh  Perl.  Contact  "mpw-perl- 
equest@iis.ee.ethz.ch." 

Timothy  Murphy*  also  ported  a  version  of  perl  to  the  Macintosh  using  Think  C.  It 
has  probably  been  abandoned  in  favour  of  the  MPW  port,  but  is  still  available  at 
ftp.maths.tcd.ie  [134.266.81.10]  in  the  directory  /pub/Mac/perl-4.035/. 

*  OS/2  sources  are  also  available  at  ftp.cis.ufl.edu  in  /pub/perl/src/os2.  This  appears  to 
have  been  abandoned  and  added  to  the  official  distribution.  See  the  directory  os2  in 
the  perl5  sources. 

*  VMS  systems  should  be  able  to  build  directly  from  the  standard  distribution. 


There  is  much  more  Information  at  URL 
ftp://ftp.cis.ufl.edu/pub/perl/doc/faq 
Jim  Augins 
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APPENDIX  E:  BRIEFING  CHARTS  AVAILABLE  THROUGH  RUTH  EAGLE 
eagle@rand.org,  PHONE  (310)  393-0411,  X6207,  FAX  (310)  393-4818 

1.  Technical  Architecture  Framework  for  Information  Management  (TAFIM):  Ken 
Kaufman 

2.  3COM  AccessBuilder  Remote  Access  Servers:  Joan  McCaffrey  (Me  Info) 

3.  Simulation  and  Human  Systems  Technology  Division:  Kevin  Boner 

4.  Universal  Threat  System  for  Simulators:  Jim  Santangelo 

5.  Requirements:  Luci  Haddad 
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THE  AUTHORITATIVE  DATA  SOURCES  SUBGROUP  MEETING  AT  IDA 
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9.2  MAIN  OBJECTIVES  OF  MEETING 

As  a  result  of  the  15  July  1994  meeting,  Mr.  Hopkins  requested  subgroup  members  for  points  of 
contact  for  authorized  data  sources  and  centers.  On  12  August,  he  followed  up  by  creating  and 
faxing  a  data  sheet  form  for  identified  POCs  to  provide  data  description  information  on  their 
sources/centers.  An  overwhelming  positive  response  resulted  in  approximately  70  sources 
providing  information.  The  purpose  of  the  9  September  meeting  was  to  assess  the  results  of  the 
information  provided  and  determine  the  direction  to  proceed  in  developing  the  Data  Sources 
Directory  (DSD). 
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9.3  MEETING  NOTES 

a.  Dr.  Chien  Huo  of  DISA/DMSO  began  by  pledging  his  support  to  the  ADS  Subgroup 
efforts  Working  with  Mike  Frame  of  IDA,  he  plans  to  use  DMSO  support  to  place  the 
DSD  on  the  World  Wide  Web(WWW)/MOS  AIC  Internet.  Mr.  Spaulding  raised  the 
question  of  potential  network  overload  in  the  twenty-first  century.  Dr.  Huo  wants  to  use 
WWW  because  of  its  wide  spread  availability  and  open  systems  environment  capability. 

b  Mr  Hopkins  reviewed  the  current  results  of  his  survey.  Regarding  the  entry  on  the 
survey  form  "DBMS  Modeled  (Yes/No)  (Planned/Not  Planned),"  discussion  ensued  on 
the  DoD  Enterprise  Model  and  C2Core.  Dr.  Huo  explained  that  the  Enterprise  gives  the 
overall  view  whereas  the  C2Core  Data  Model  gives  specific  applications.  Integration 
efforts  occurred  last  fall;  C2Core  extends,  not  replaces.  Enterprise.  The  top  level  has 
been  incorporated.  A  DDRS  query  shows  which  C2Core  elements  have  been  approved 
and  incorporated  into  Enterprise.  The  intent  of  the  question  on  the  form  was  to  determine 
if  the  DBMS  had  been  modeled--not  necessarily  to  what.  Consensus  of  the  group  is  that 
the  intent  of  the  question  should  be  use  of  IDEF1X.  If  not  EDEF1X,  what  modeling 
technique  was  used? 

c.  The  subject  of  M&S  Data  Categories  was  discussed.  Mr.  Dunn  explained  that  due  to  the 
responses  on  his  earlier  Data  Categories  review,  he  had  decided  to  leave  the  major 
categories  as  they  are  for  the  purposes  of  completing  the  source/center  information 
survey.  Respondents  can  utilize  the  sub-category  to  differentiate  their  respective 
functions.  Dr.  Huo  wants  to  ensure  everyone  agrees  with  the  categories  architecture 
before  putting  the  DSD  in  WWW/MOSAIC. 

d.  The  term  "Authoritative"  was  debated  for  ADS  purposes.  As  an  example  in  the  Army, 
which  is  authoritative-DMA  or  Topographic  Engineering  Center  for  terrain?  Mr. 
Ralston,  co-chair  of  the  Data  Guidelines  subgroup,  advised  that  implementation  of  the 
DSD  will  force  policy  decisions  because  of  new  or  less  well-defined  customers  who  will 
be  requesting  data  access. 

e.  Dr.  Huo  revisited  the  subject  of  Responsibilities.  Mr.  Ralston  said  that  this  is  being 
resolved  in  the  Data  Guidelines  subgroup.  As  they  develop  the  responsibilities,  the  ADS 
subgroup  should  coordinate  with  them. 

f.  Dr.  Huo  stated  that  a  Data  Security  Task  Force  was  being  fanned  and  that  we  should 
coordinate  with  them.  He  also  passed  out  a  White  Paper  which  covers  Iris  Kameny  s 
goals.  He  challenged  the  group  to  consider  establishment  of  Executive  Data  Agents  (e.g. 
Environment,  consisting  of  Ocean,  Atmosphere,  and  Ground).  He  asked  the  group  to 
review  the  paper  and  return  comments  ASAP. 

g.  Group  members  were  concerned  about  the  fact  that  entries  into  the  source/center  survey 
have  not  been  officially  blessed  by  their  commands  or  agencies.  Dr.  Huo  will  provide  a 
DMSO  survey  memo  requesting  that  the  data  source/center  information  base  be  reviewed 
and  released. 

After  an  IDA  demonstration  of  WWW/MOSAIC,  the  meeting  adjourned  at  1445. 
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9.4  ACTION  ITEMS 


a.  Dr.  Huo  requested  the  ADS  group  prepare  a  "Public  Relations"  advertisement  for  the 
Data  Sources  Directory  similar  to  the  Army  MOSAIC  model  catalog  tri-fold. 

b.  Dr.  Huo  further  requested  that  a  charter  including  the  mission  and  responsibilities  of  the 
ADS  subgroup  be  developed. 

c.  The  following  were  tasked  to  follow  up  on  data  source/centers  which  had  been  identified 
but  who  had  not  yet  responded. 

#  Taskee  Data  source/center 


1.  Mr.  Burch 

2.  Ms.  Schroeder 

3.  LTCOL  Hogg 

4.  Mr.  Coale 

5.  Mr.  Spaulding 

6.  Mr.  Danko 

7.  Mr.  Hopkins 

8.  Mr.  Dunn 

9.  MAJ  Bar  land 
10.  Dr.  Huo 


ARMS 

Navocean 

Marine  Corps 

DIA 

NASA 

DMA 

BMDO,  Defense  Mgt  Data  Center,  SIMA,  MLLB,  AFMC 
Various  Army,  MDDC,  KDEC 
Various  Air  Force 
NEON  and  BFTT 


Target  for  submissions  is  3  October  to  Mr.  Hopkins. 
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9.5  NEXT  MEETINGS 

The  next  Data  Guidelines  meeting  will  be  on  18-19  October  at  IDA.  The  next  ADS  meeting  will 
be  in  Tampa  in  conjunction  with  the  CENTCOM-hosted  Fourth  Annual  Joint  M&S  Database 
Conference  meeting  the  first  week  in  November. 
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10.1  AGENDA 


0830  -  0845 
0845  -  0915 
0915  -  0945 
0945-  1100 

1100- 1115 
1115-1145 
1145-1215 
1215-1300 
1245  -  1345 

1345  -  1430 
1430  -  1700 


MONDAY,  OCTOBER  17, 1994 

Review  of  objectives  and  issues  of  Repository  Subgroup:  Jim  Augins 

Overview  of  MSRR  portions  of  Master  Plan:  Iris  Kameny 

Identification  of  MSRR  prototype  Object  Set:  Peter  Valentine 

Identification  of  existing  developmental  components  that  could  be  incorporated 
into  the  MSRR  -  ALL  please  provide  inputs  with  budget  estimates  of  effort 
required  to  Jim  Augins  prior  to  OCT  10 

Break 

Description  of  NWTDB  SIDS  Tool:  SWL 


Lunch 

Identification  of  components  of  MSRR  that  need  to  be  designed  and  built  from  the 
ground  up:  P.  Valentine  with  inputs  submitted  from  ALL  send  to  Pete  prior  to 
OCT  10 

Status  presentation  from  the  Complex  Data  Task  Force:  TBS. 

Working  session  to:  define  tasks  to  be  carried  out,  how  these  will  coordinate  with 
activities  briefed  earlier,  and  development  of  roadmap:  led  by  Jim  Augins  and 
Peter  Valentine,  with  active  participation  of  Iris  Kameny  and  Chien  Huo 


REPOSITORY  SUBGROUP  MEETING  AT  IDA 
MONDAY,  OCTOBER  17,  1994 
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10.3  MAIN  OBJECTIVES  OF  MEETING 

Main  objectives  of  working  meeting:  (1)  to  review  and  refine  MSRR  planned  tasks  identified  at 
August  meeting;  (2)  to  determine  how  they  should  be  coordinated  with  other  relevant  activities 
and  the  tentative  master  plan;  and  (3)  develop  a  roadmap  for  carrying  them  out. 
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10.4  MEETING  NOTES 

Note  two  changes  in  names  and  acronyms:  . 

_  Information/Database  Technology  Working  Group  (I/DBTWG)  to  Data  and  Repositories 

Technology  Working  Group  (DRTWG) 

—  Information  Resource  Repository  (IRR)  to  M&S  Resource  Repository  (MSRR) 

Mr.  Jim  Augins:  Review  of  Repository  Subgroup  Objectives  and  Issues 
The  main  objective  of  the  Repository  Subgroup  is  to  provide  M&S  data  and  information 
resources  to  support  the  following  M&S  community  groups  (the  counts  are  of  those  people  at  the 
meeting  who  consider  themselves  to  be  part  of  that  respective  group). 

Warfighter  (1) 

Data  Administration  Community  (6) 

Training  and  Exercise  Community  (7) 

Analysis  (R&D,  P&L)  (3) 

Test  and  Evaluation  (5) 

M&S  System  Developers  (0) 

The  MSRR  requirements  can  be  categorized  into  three  groups:  Architecture,  contents  and  tools. 

Augins  characterized  the  architecture  as  distributed,  modular  and  heterogeneous  environment 
vice  TAFIM.  This  evoked  some  discussion  as  to  why  he  didn't  consider  the  TAFIM  broad 
enough  to  support  the  entire  M&S  community  where  DIS  A  considers  it  broad  enough  to  support 
the  DoD  community.  This  issue  will  be  visited  again  during  the  repository  requirements  analysis 

task. 

The  MSRR  contents  include:  Instance  databases,  metadata,  directories/catalogs,  algorithms,  and 
models  and  simulation.  The  tools  must  support  directory  access,  browsing,  linking, 
configuration  management,  and  security. 

Four  DMSO  Master  Plan  issues  were  identified: 

(1)  Access  and  use  of  M&S  resources  across  DoD 

(2)  Identification  of  Authoritative  Data  Sources  for  M&S  resources  and  establishment  ot 
common  data  standards 

(3)  Configuration  control  of  M&S  reusable  resources  (data,  algorithms,  models, 
simulations), 

(4)  Identification  of  data  security  requirements. 

Augins  identified  12  Repository  Subgroup  issues:  , .  _p  c 

(1)  Defining  an  MSRR  to  cover  all  functional  needs  of  managing  metadata,  data,  and  M&5 

(2)  Addressing  communications  standards  to  support  interoperation,  information  exchange 
and  browsing 

(3)  Identifying  security  concerns 

(4)  Insufficiencies  of  DDRS  repository  and  other  standards  such  as  FIPS  156 

(5)  Addressing  multi-valued  instance  data  with  respect  to  source  and  classification  (given  it 
comes  from  different  sources  and  the  instances  may  be  at  different  classification  levels. 

(6)  Objects  vice  data 

(7)  Repository  update  requirements  for  both  metadata  and  instance  data  (currency  and 
synchronization  problems) 

(8)  Real  world  vice  M&S  data 

(9)  Archive  and  retrieval  of  M&S  data  sets,  M&S  results  and  conclusions,  and  mapping 
between  inputs  and  results  and  conclusions 

(10)  File  interface  standards 
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(11)  Lack  of  a  common  open  interface  between  CASE  tools 

(12)  Metadata  for  tagging  quality,  security,  and  audit  trail 

Iris  Kameny:  Overview  of  MSRR  Portions  of  the  Draft  Defense  M&S  Master  Plan 

There  are  five  main  points  about  data  and  repositories: 

(1)  DMSO  is  the  FDAd  for  M&S 

(2)  DRTWG  has  developed  well  defined  set  of  needs  and  plans  for  the  M&S  community  in 
the  data  area 

(3)  TWISTIAC  serves  as  a  clearing  house  for  knowledge  and  activities  related  to  M&S 

(4)  Next  step  is  to  develop  policies  and  procedures  in  areas  of  complex  data,  data  VV&C, 
authoritative  data  sources,  and  configuration  management  of  information  resources 

(5)  Need  to  develop  an  intemetted,  distributed  MSRR 

There  are  three  areas  recognized  in  the  Master  Plan  as  needing  authoritative  representations  that 
will  require  authoritative  data  sources,  VV&C,  resource  repositories  and  configuration  control. 
They  are  environment  (terrain,  atmosphere,  ocean),  systems  (major  platforms,  weapons,  units, 
life  support,  C4I,  and  logistics),  and  human  behavior  (human  capabilities  and  limitations, 
individual  and  group  performance,  effects  of  organizational  configuration  on  performance,  C3 
and  doctrine  and  tactics). 

The  main  issues  with  providing  MSRR  to  meet  developer  and  end  user  needs  were  described 
earlier  as  the  4  Master  Plan  issues.  Actions  that  are  to  be  taken  are  to  develop:  (1)  an  MSRR,  (2) 
taxonomy  and  directory  of  authoritative  data  sources  and  common  data  standards,  (3)  MSRR 
configuration  control  procedures  and  tools,  and  (4)  specific  M&S  data  security  requirements. 

The  road  map  to  developing  the  MSRR  calls  for: 

—  Requirement  definition  by  IQ  FY96 

—  Prototype  (for  FDAd  MSRR)  by  IQ  FY97 

—  Limited  testbed  by  2Q  FY98 

—  Initiate  DoD-wide  distribution  FY99 

—  Complete  distribution  in  FYOO 

Chien  Huo:  Draft  Defense  M&S  Master  Plan 

Chien  Huo  passed  out  copies  of  the  new  draft  Defense  M&S  Master  Plan  and  briefing  charts  on 
(1)  Sub-Objective  5-2  key  actions  toward  developing  methodologies,  standards,  and  procedures 
for  the  VV&A  of  M&S  and  the  VV&C  of  data;  (2)  Sub-objective  5-3  key  actions  to  provide  a 
resource  repository  system  to  meet  developer  and  user  needs;  (3)  M&S  Data  Administration  road 
map  from  95-96  through  2001;  and  (4)  a  list  of  DMSO  Sub-Working  Groups,  including 
Functional  WGs,  Technology  WGs  and  Task  Forces  showing  their  organization  prior  to  May  94, 
at  present,  and  proposed. 

Peter  Valentine:  Identification  of  MSRR  Prototype  Object  Set 

—  Peter  discussed  the  M&S  Information  gopher  at  DTIC  accessible  through 
gopher//dmso.dtic.dla.mil  which  contains  all  the  current  information  about  the  DRTWG, 
including  notes  from  DRTWG  meetings,  Task  Forces  and  subgroups,  membership  lists, 
etc. 

—  The  World  Wide  Web  (WWW)  access  to  pages  at  JDBE,  NRaD  (repository)  and  DMSO 
can  be  accessed  through  WWW  HTTP//138.27.204.18/.  The  WWW  provides  a 
hypermedia  interface  and  is  inherently  distributed.  There  is  user-friendly,  free,  MOSAIC 
client  software  available  for  all  platforms  using  WWW 

—  It  was  suggested  that  we  may  want  to  support  implementation  of  WWW  home  pages  at 
various  places,  including:  repository  (NRaD),  JDBE,  Authoritative  Data  Sources 
(CENTCOM),  VVC  (RAND) 

—  JDBE  data  models  are  currently  supported  by  the  ERwin  tools  that  can  be  printed  via 
postscript  files 
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—  A  Common  Gateway  Interface  (CGI)  standard:  can  provide  a  user  interface  to  databases 
independent  of  DBMS  products;  it  has  just  been  made  available  in  WWW  form 

—  Access  to  database  and  M&S  directories:  suggested  Oracle  through  MOSAIC  browser, 
JDBE  is  experimenting  with  CGI  part 

—  Use  Army  Mosaic  to  populate  the  M&S  directory 
—  Battelle  to  populate  the  DB  directory? 

—  Use  WWW  to  help  capture  data  for  directories 

—  Discussed  new  Army  Information  on  Models,  Simulations,  and  Studies  System 
(AIMSSS)  that  consists  of 

—  Army  Mosaic 

_ VV&A  Repository  Online  of  Models  and  Simulations  (VVAROOM) 

—  Summary  page  for  each  Army  study  conducted  over  past  five  years 
_ Tagging:  how  do  we  deal  with  security  and  quality  tags  and  audit  trail  tags? 

James  Mathwick:  Description  of  NWTDB  System  Information  Directory  (SID)  Tool 

_  SID  purpose:  to  serve  as  a  tool  for  managing  the  integration  of  Distributed  Information 

Systems  in  support  of  the  tactical  commander 

_ Design  criteria:  evaluate,  migrate,  manage  integration  of  information  from  diverse 

sources  and  environments;  integrate  tools,  services,  and  utilities  from  diverse  sources 

_ Tasks:  (1)  register  and  maintain  current  view  of  existing  systems;  (2)  promote 

consensus  view  of  information  requirements;  (3)  migrate  to  DoD  standards 
—  SID  requirements  are  a  wish  list  tt 

—  There  is  an  IDEFO  model  for  "conducting  Navy  Information  Management 
—  SID  federation  of  automated  tools  include:  CASE  tools  such  as  IE  Expert,  IE 
Advantage;  ERwin/ERx  (IDEF1X);  BPwin  (IDEFO);  and  ObjectView  and 
PowerView 

Discussion;  In  Reference  to  FY-95  MSRR  Planning  Budget 

Task  A:  Need  to  redo  Subtask  A,  MSRR  Requirements  Analysis  and  Identification,  and  expand 
its  scope 

—  Subtask  1:  will  be  the  requirements  subtask  to  include:  . 

—  Development  of  IDEFO  models  (for  M&S  FDAd,  M&S  DA,  and  M&S  organizations 

submitting  standards)  . 

_  Coordinate  IDEFO  models  for  M&S  organization  submitting  standards  with  Services 

and  within  each  Service  across  functional  communities 
—  Extend  IDEFO  models  to  data  centers,  reuse  repositories,  DIS  exercises  and  post 

processing  .... 

—  Develop  metamodel  for  repository  objects:  data  standards;  data  administration 
models;  directories;  instance  data/exchange  between  centers,  security,  common 
domains,  etc.;  M&S  reuse  repository;  DIS  exercise  stuff 
—  JDBE  could  support  IDEFO  and  IDEF1X  modeling  efforts 

—  Subtask  2:  change  old  3  to  Subtask  2:  define  and  Document  choice  of  Platform  and 
Development  Environment,  etc.:  address  Sun  and  PC  environment 

_  Subtask  3:  change  old  2  to  Subtask  3:  develop  Alternatives:  include  white  paper  on  lack 

of  compliance  with  TAFIM  if  that  is  an  alternative 

—  Products:  add  IDEFO  models,  IDEF1X  metamodel.  Alternatives  Analysis  Document  to 
Draft  Systems  Requirements  Document  and  System  Development  Plan 

TaskB:  Change  name  to  Prototype  MSRR  Data  Resource  Exchange  Architecture 

—  Subtask  1:  change  old  2  to  Subtask  1,  "Implement  Prototype  Architecture  Design 

—  Subtask  2:  change  old  1  to  Subtask  2:  support  M&S  community  in 
Creation/Maintenance  of  WWW  servers:  include  support  for  SMEs 

—  Subtask  3:  change  name  to  refer  to  prototype:  build  WWW  Interface  for  the  Prototype 
M&S  and  Database  Directories 
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—  Reconsider/remove  Subtask  4:  modify  existing  unclassified  versions  of  high  interest 
systems  (TBS  ,  e.g.,  ARMS,  SID)  to  incorporate  a  WWW  interface  for  interfacing  with 
MSRR 

—  Issue:  could  be  done  as  part  of  some  M&S  data  project; 

—  Separate  security  issue  and  address  in  Security  Task  Force 

Task  C:  Provide  First  Increment  of  Tools  to  Support  M&S  FDAd  Prototype  Repository  . 

Consists  of  two  options:  suggestion  is  to  look  across  Options  I  and  II  and  further.  The  intent  is 
to  meet  immediate  requirements. 

—  Tools  should  support  prototype  MSRR  for  FDAd 

_  Option  1.1,  Integrate  ADEF  tools  with  WWW:  need  better  definition  of  this  subtask  and 

a  better  evaluation  of  ADEF  from  the  DAPMO 

—  Option  1.2,  Create  consolidated  metamodel  for  M&S  community:  this  should  be 
coordinated  with  Task  A.l;  metamodel  developed  in  Task  A.l  and  Task  C  could  look  at 
interchange  format  for  metamodel 

_  Option  1.3,  Create  a  Data/Proposal  package  tracking  database:  this  should  be  included 

and  online 

—  Option  II:  install  an  enhanced  version  of  the  NWTDB  SID  system  and  process  to  support 
the  M&S  FDAd.  Discussion  of  SID  for  MSRR:  seems  to  be  going  on  independently  of 
DDR,  and  it  is  hard  to  know  how  much  of  it  is  real.  If  we  are  going  to  evaluate  SID  as 
part  of  the  MSRR  effort,  we  need  to  discuss  with  Carla  Von  Bemewitz  who  received  a 
briefing  on  it  and  we  need  an  annotated  briefing  or  white  paper,  something  more 
definitive  than  the  briefing  we  were  given 

Task  D:  Develop  capability  to  support  distributed  heterogeneous  database  query  generation  and 

data  access  over  WWW  . 

—  Have  to  show  need  for  this  and  statement  about  data  components  to  make  this  widely 

releasable 

—  Look  at  commercial  products 

Task  E:  Provide  a  First  Increment  Software  Reuse  Repository  and  define  unmet  requirements: 
this  should  be  part  of  Task  A  requirements  Subtask  1  and  should  be  coordinated  with  the  Army 

Task  F:  Repository  Working  Group  Support:  make  this  part  of  the  other  tasks 

Task  G:  Program  Management:  leave  in  as  a  task 

Summary:  The  Repository  Subgroup  needs  to  clean  up  the  task  list. 
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10.5  ACTION  ITEMS 

For  Jim  Augins  and  Pete  Valentine 

1 .  The  DRTWG  needs  a  written  understanding  of  what  the  M&S  Repository  is,  what  will  be 
implemented,  and  assurance  that  it  is  consistent  with  DoD  data  administration 

2.  The  Repository  subgroup  needs  to  clean  up  the  Repository  task  list. 

3.  The  Repository  Subgroup  needs  to  identify  representatives  from  the  Components  to 
participate  in  the  Subgroup  and  Tasks 

4.  The  Repository  Subgroup  needs  to  organize  a  steering  group  to  lead  the  five  tasks 

Chien  Huo  and  Iris  Kameny 

5.  Call  the  Army  (Lana  McGlynn)  to  ask  who  Army  assignees  are  to  different  DRTWGs 
(and  also  other  services) 

6.  Go  back  to  services  for  MSRR  requirements  and  invite  them  to  a  requirements  meeting 

Issues  Identified:  m „  _  .  , 

1.  Is  TAFIM  broad  enough  architectural  standard  to  serve  the  M&S  community '  Meed 
white  paper  to  discuss  TAFIM  compliance/non-compliance 

2.  Present  issue  to  DDRS  Steering  community:  need  common  architecture  for  data 
standards  repository,  software  reuse  repository,  database  repositories.  The  MSRR 
concept  and  implementations  need  to  be  coordinated  across  DoD. 

3.  Chien  Huo  needs  to  publish  procedures  for  use  of  data  standards  (e.g.,  DDRS  access, 
etc.).  The  DRTWG  community  need  to  let  him  know  if  they  have  DDRS  access,  etc. 
There  is  also  a  need  for  establishing  policy  and  procedures  for  accomplishing  data 
standards  within  the  M&S  community. 

4.  Need  to  develop  policy/procedures  to  make  Services  responsible  for  implementing, 
populating,  and  maintaining  their  own  database  and  M&S  directories,  and  being  able  to 
do  distributed  access  to  all  directories  built  on  common  data  model. 

5.  DoD  needs  to  produce: 

—  IDEFO  model  of  how  the  DoD  does  information  management 
—  The  DoD  data  standards  (DDRS)  requires  a  metadata  model  of  the  data  elements  that 
describe  DoD  standard  data  elements 

6.  Shareability  and  releasability  of  data  needs  to  be  addressed 
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11.1  AGENDA 

TUESDAY  -  WEDNESDAY,  OCTOBER  18-19, 1994 


Main  objectives  of  working  meeting: 

(1)  To  review  and  refine  Data  VV&C  Guidelines  Subgroup  tasks  identified  at  July 
meeting; 

(2)  To  determine  how  they  should  be  coordinated  with  other  relevant  activities  and  the 
master  plan;  and 

(3)  Develop  a  roadmap  for  carrying  them  out. 

TUESDAY  OCTOBER  18, 1994 


0815-0845 
(Added) 
0845  -  0915 

(Added) 
0915  -  0945 

0945  -  1030 
1030-  1100 
1100-1145 

1145-1215 
1215-1315 
1315-1345 
1345 . 1445 
1445  -  1700 


0830  -  1200 

1200-  1300 
1300  -  1400 


Review  of  objectives  and  issues  of  VV&C  Task  Force:  Iris  Kameny 
DMSO  Activities:  Dr.  Chien  Huo 

Overview  of  W&A  of  Distributed  Simulations  Project  and  results  of  September 
21 IPR:  Pam  Blechinger 

IDEF0  Modeling  of  the  DIS  W&A  Process:  Peggy  Gravitz 

Report  on  VV&A  of  Distributed  Simulations,  Data  Consistency  Task  (IPR 
September  21):  Susan  Solick 

Report  on  DIS  VV&A  WG  held  in  Orlando  Sept  26-30:  Simone  Youngblood 
Break 

Report  on  MORS  SIMVAL  Workshop  held  in  Albuquerque  September  29-30: 
Bob  Harding 

Update  on  Navy  VV&A:  Bob  Hartling 
Lunch 

Report  on  RAND  VV&A  Primer  Progress:  Bruce  Bennett 

Discussion  of  morning  topics:  led  by  Bob  Hartling  and  Mark  Ralston 

Working  session  to:  define  tasks  to  be  carried  out,  how  these  will  coordinate 
with  activities  briefed  earlier,  and  development  of  roadmap:  led  by  Bob  Hartling 
and  Mark  Ralston,  with  active  participation  of  Iris  Kameny  and  Chien  Huo 

WEDNESDAY,  OCTOBER  19, 1994 

Working  session  on  Database  Quality  Profile:  Jeff  Rothenberg  (need 
participation  from  data  centers) 

Lunch 

Report  on  Authoritative  Data  Sources  status  and  plans:  Bill  Dunn  and  Mike 
Hopkins 
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1400  -  1700  Discussions  TBD  during  meeting:  Led  by  Iris  Kameny 
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11.3  ACTION  ITEMS 

(1)  Peggy  Gravitz  to  distribute  copies  of  the  IDEFO  process  model  for  DIS  VV &A. 

(2)  Group  to  provide  changes  and  additional  input  to  the  list  of  authoritative  data  sources 
cincl  dcitci  centers 

(3)  JDBE  to  convert  Authoritative  Data  Sources  directory  to  a  PC  database  file. 

(4)  Upcoming  Meetings:  (a)  DIS  VV&A  process  modeling  group  will  meet  in  Huntsville 
15-16  November,  (b)  Authoritative  data  sources  subgroup  will  meet  during  the 
CENTCOM  M&S  Database  Conference,  3  November. 

(5)  Summary  of  actions  with  respect  to  Data  VV&C  tasks  1-3 

(1)  Initial  definitions  are  OK 

(2)  Chien  Huo  will  get  back  to  the  co-chairs  with  dollars  and  timing  information  as  to 
when  funds  will  be  available 

(3)  Task  1  people  will  produce  at  least  5  IDEFO  models  (Army,  Air  Force,  Navy, 
OSD,  and  either  Marines  or  JCS) 

(4)  Mark  Ralston  would  like  to  get  more  detailed  task  descriptions  and  decide  on  the 
leaders  of  Tasks  and  Subtasks 

(5)  Will  require  DMSO  funding  support  for  Task  leaders 

(6)  SAG  oversight  will  be  Hartley  and  Ralston:  Task  leaders  will  create  their  plans 
and  their  organization  will  be  responsible  for  carrying  them  out 

Financial  Management: 

( 1 )  Will  use  FY95  DMSO  dollars 

(2)  Contracting  vehicle  choices 

a.  IDEFO  contractor  support  from  DMSO  (e.g.,  JDBE,  COLSA) 

b.  Government  organizations  need  to  share  their  contract  vehicle  possibilities  with 
DMSO 

Task  Management: 

(1)  Task  1:  will  run  March  to  Sept  and  produce  draft  guideline  and  be  led  by  Lt  Col  Denny 
Lester 

(2)  Task  3:  has  no  assigned  leader,  can  start  when:  a  leader  is  identified,  participants  are 
identified  and  willing  (e.g.,  DMA,  DIA,  Oceanographic,  JTAMS),  funding  is  available 

(3)  The  co-chairs  need  to  identify  a  leader  for  Task  3 

(4)  Chien  Huo  will  give  the  co-chairs  a  statement-of-work  (SOW)  example  they  can  use  for 

format  and  content  . 

(5)  Chien  Huo  and  Dave  Danko  will  talk  with  Bob  Jacober  (DMA)  about  doing  an  IDEFO 

model 

Denny  Lester  observed  that  problems  with  diving  into  this  are  that  there  is  too  much  to  do, 
asks  are  overlapping;  and  those  working  on  the  tasks  take  risk  of  being  spread  too  thin. 
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11.4  PRESENTATIONS  AND  GROUP  DISCUSSION 

(1)  Review  of  objectives  and  issues  of  VV&C  Task  Force:  Iris  Kameny,  RAND 

Ms.  Kameny  identified  the  objectives  of  the  Data  W&C  Task  Force  as:  (a)  Develop 
guidelines  for  performing  data  VV&C  to  include  definition  of  the  process,  development 
of  cost  models  and  databases,  and  development  of  a  quality  profile  for  databases,  (b) 
Identify  authoritative  data  sources  and  data  centers  and  define  their  responsibilities. 
There  were  no  suggested  changes  to  the  objectives. 

(2)  DMSO  Activities:  Dr.  Chien  Huo,  DMSO 

Dr.  Huo  discussed  the  new  DMSO  organization: 

Director  DMSO:  CAPT  Jim  Hollenbach,  USN 
Deputy  Director  DMSO:  COL  Jerry  Wiedewitsch,  USA 
Chief  of  Staff:  Mr.  Gary  Yerace 
Science  and  Technology  Division:  Chief  Scientist  (TBD) 

Technology  Application  Division:  CDR  Gary  Misch,  USN 
Operations  Division:  Lt  Col  Dave  Bartlett,  USMC 
Business/Financial  Management  Division:  Mr.  Waverly  Debraux 

Dr.  Huo  distributed  copies  of  the  30  September  94  draft  Modeling  and  Simulation 
Master  Plan.  He  indicated  that  the  first  priority  identified  in  the  Master  Plan  is  M&S 
architecture  followed  by  data  standardization.  Dr.  Huo  reviewed  recent  changes  in  the 
DMSO  organization.  Functional  data  administration  will  be  performed  in  the  Science 
and  Technology  Division. 

The  Information/Database  Working  Group  will  be  renamed  the  Data  and  Repositories 
Technology  Working  Group  (DRTWG).  Dr.  Huo  and  Ms.  Kameny  have  been 
appointed  as  chairs  of  the  Data  and  Repositories  Working  Group.  A  final  decision  was 
scheduled  for  21  October.  VV&C  is  addressed  under  VV&A  objectives  in  the  Master 
Plan,  but  will  continue  to  be  addressed  in  the  Data  >and  Repositories  Working  Group 
by  the  Data  VV&C  Task  Force. 

(3)  Overview  of  W&A  of  Distributed  Simulations  Project  and  results  of  September  21 
IPR:  Pam  Blechinger,  TRAC 

The  main  goal  of  this  DMSO-sponsored  task  is  to  define  and  document  the  distributed 
simulation  VV&A  process.  It  is  currently  working  with  the  DIS  W&A  Working 
Group  toward  reviewing,  refining  and  expanding  die  DIS  VV&A  process.  Current 
participants  in  the  task  are  TRAC,  SSDC,  AMSAA,  NAWC  TSD,  SPACECOM,  and 
Wright  Labs.  Current  funding  for  this  task  is  $700K  of  DMSO  funding  with  $  1M  of 
matching  funds  from  the  project  participants.  The  first  phase  of  the  project  is  scheduled 
for  31  March  1995  completion.  The  first  year  effort  concentrates  on  verification  tools, 
techniques,  and  procedures  for  DIS  applications.  The  second  year  effort  will  address 
validation.  Specific  technical  tasks  include: 

(a)  Develop  procedures  to  determine  algorithm  consistency. 

(b)  Develop  procedures  and  tools  to  measure  network  overload. 

(c)  Evaluate  DIS  compliance  testing. 

(d)  Develop  procedures  to  determine  database  consistency. 

(e)  Test  verification  techniques. 

(f)  Validate  and  accredit  the  North  American  and  US  Space  Command  Integrated  C2 
Analyst  Test  Environment  (NATE)  composite  model.  NATE  is  not  DIS 
compliant. 

(g)  Collect  tools  useful  for  VV&A. 
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(h)  Produce  a  VV&A  implementation  guide. 

The  current  model  for  DIS  VV&A  was  reviewed.  The  question  was  raised  as  to  what 
the  "DIS  Repository"  contains.  Ms.  Kameny  suggested  that  this  should  include  data 
standards,  models  and  simulations,  instance  data,  complete  DIS  exercises,  and  the  tools 
to  manipulate  these  objects. 

To  date,  an  IDEFO  process  model  of  the  DIS  VV&A  process  has  been  developed.  This 
model  goes  3  to  4  levels  deep  in  its  description  of  the  process.  Ms.  Blechinger  asked 
for  help  from  the  M&S  community  in  refining  the  process  model  in  the  areas 
addressing  W&C  of  data. 

There  is  a  need  to  define  the  terms:  compliance,  compatibility,  and  interoperability. 
Both  this  project  and  STRICOM  are  trying  to  define  these  terms.  A  white  paper 
discussing  compliance  is  available. 

A  draft  of  the  Methodology  Handbook  is  available.  Future  activities  include: 

(a)  Refinement  of  the  process  model, 

(b)  Reconciliation  of  the  Compliance  Testing  Specification  with  the  1ST  compliance 
test  suite, 

(c)  Testing  the  process  defined  in  the  IDEFO  model, 

(d)  Completing  the  Methodology  Handbook  ( planned  completion  March  1995)  and 
beginning  the  implementation  guide 

(e)  Establishing  second  year  funding  to  address  validation  and  accreditation. 

(4)  IDEFO  Modeling  of  the  DIS  VV&A  Process:  Peggy  Gravitz,  COLSA  Corp. 

The  initial  development  of  the  IDEFO  process  model  for  DIS  VV&A  was  developed 
using  groupware  at  MICOM's  Electronic  Meeting  Systems  facility  at  Redstone  Arsenal. 
This  allowed  collaborative  development  of  the  model.  The  development  of  the  model 
took  5  days.  The  model  has  since  been  transferred  and  is  being  further  developed  using 
the  BPWin  software.  Ms.  Gravitz  circulated  a  sign-up  list  to  receive  copies  of  the 
IDEFO  model.  Ms.  Gravitz  also  provided  copies  of  a  paper  she  and  William  Jordan, 
SSDC,  developed  entitled  "Utilizing  IDEFO  for  Examination  of  the  Individual 
Activities  of  the  DIS  VV&A  Process  Model."  This  paper  gives  further  insight  into  the 
process  of  developing  the  IDEFO  model. 

(5)  Report  on  VV&A  of  Distributed  Simulations,  Data  Consistency  Task:  Susan  Solick, 
TRAC 

DIS  data  W&C  model  assumptions:  ( 1 )  data,  for  the  most  part,  have  previously 
undergone  W&C  at  the  component  level  (V&V  agents  review  records  before  data  and 
components  are  accepted  for  DIS  exercise,  and  deficiencies  are  identified  and  corrected 
by  component  and  data  sponsor);  and  (2)  data  V&V  must  occur  before  the  DIS  exercise 
can  be  validated. 

Ms.  Solick  identified  those  portions  of  the  IDEFO  model  that  address  data  constancy  in 

the  VV&A  of  DIS:  .  ,  , 

(a)  Activity  A.2.2.4  -  Evaluate  data  and  database  requirements  includes: 

[1]  Review  documents 

[2]  Examine  databases  and  sources  for  data  availability  and  credibility 

[3]  Evaluate  data  congruity 

(b)  Activity  A.2.3.4  -  Evaluate  data  and  database  designs  includes: 

[  1  ]  Verify  data  implementation 

[2]  Evaluate  data  consistency 
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[3]  Assess  data  collection 

Ms.  Solick  indicated  that  the  "key  elements"  addressed  in  the  process  model  are  those 
involved  in  the  interfaces.  Ms.  Kameny  observed  that  the  interface  data  requirements 
could  be  derived  from  the  requirements  for  data  local  to  the  components  in  the 
simulation. 

Jeff  Rothenberg  raised  the  concern  that  the  process  model  may  artificially  separate 
model  VV&A  from  data  VV&C  where  two  processes  are  tightly  coupled. 

(6)  Report  on  DIS  W&A  WG  held  in  Orlando  Sept  26-30:  Simone  Youngblood,  Johns 
Hopkins  APL 

The  goals  of  the  DIS  VV&A  for  the  1 1th  workshop  were: 

(a)  Develop  a  DIS  VV&A  "Recommended  Practices"  document 

(b)  Refine  and  expand  the  DIS  VV&A  process 

(c)  Define  and  integrate  DIS  VV&C  requirements  into  the  W&A  process 

(d)  Identify  and  develop  methods,  techniques,  and  tools  for  performing  DIS  VV&A 
and  VV&C  process 

(e)  Define  DIS  W&A  and  exercise  repository  requirements. 

The  DIS  W&A  process  is  being  proposed  as  an  IEEE  standard  -  Fidelity  Management 
and  usability  Guidelines. 

A  paper  on  the  DIS  need  for  DoD  data  standards  was  presented  at  the  workshop  and  a 
petition  was  circulated  to  set  up  DIS  special  interest  group  on  data  standards  and 
repositories.  The  petition  was  circulated  at  the  VV&C  meeting. 

The  DIS  VV&A  subgroup  addressed  the  role  of  the  accreditor  in  the  VV&A  process. 
They  noted  that  the  accreditor  must  be  a  participant  in  the  requirements  definition  and 
requirements  prioritization  for  a  DIS  exercise.  The  subgroup  also  discussed  how  to 
V&V  human  behavior  models  with  the  Computer  Generated  Forces  working  group. 

Ms.  Youngblood  noted  that  the  data  validation  addressed  in  the  DIS  "Develop  VV&A 
Plans"  process  is  from  the  data  producer  perspective.  She  also  indicated  that  the 
compliance  testing  of  DIS  components  is  done  "a  priori,”  not  as  a  DIS  exercise  is 
created. 

(7)  Report  on  MORS  SIMVAL  Workshop  held  in  Albuquerque  September  29-30:  Bob 
Hartling,  OPNAV 

A  major  topic  of  this  conference,  attended  by  125  participants,  was  "How  much  V&V  is 
enough?"  The  major  topics  addressed  were: 

(a)  Developing  an  accreditation  template 

(b)  Representation  of  V&V  status 

(c)  Accreditation  factors  -  criteria  for  acceptance 

(d)  Differences  in  V&V  of  legacy  simulations 

The  conclusion  at  the  conference  was  that  a  "super  template"  can  be  produced  to 
support  accreditation  which  would  provide  a  menu  of  procedures  and  techniques.  This 
template  can  then  be  tailored  for  a  specific  application.  A  strawman  template  was 
developed  and  it  will  be  posted  on  the  MORS  bulletin  board.  Jeff  Rothenberg 
suggested  that  this  should  be  considered  a  V&V  template,  not  an  accreditation  template. 
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The  conference  attendees  decided  that  it  is  possible  to  represent  a  status  of  the 
verification  process,  but  not  necessarily  the  validation  process.  The  attendees  agreed 
that  there  are  no  "units  of  V&V"  (the  levels  of  V&V  >issue).  They  also  decided  that 
the  distinction  of  "legacy"  models  was  not  a  useful  one.  The  same  VV&A  processes 
apply  equally  to  all  models.  The  only  distinction  is  the  reverse  engineering  that  is  often 
needed  for  "legacy"  models. 

(8)  Update  on  Navy  VV&A:  Bob  Hartling,  OPNAV 

Mr.  Hartling  addressed  the  VV&A  policy,  procedure,  and  guidelines  initially  developed 
by  Johns  Hopkins/APL  in  1993.  These  were  later  distributed  by  the  SPAWAR 
program.  These  policy,  procedure,  and  guidelines  call  for  4  levels  of  accreditation: 

(a)  Inspection  -  face  value 

(b)  General  -  mainly  verification 

(c)  Robust 

(d)  Endorsed 

Furthermore,  they  address  two  types  of  accreditation-domain  and  application  specific. 
Current  plans  are  to  drop  domain  VV&A.  The  Navy,  currently,  doesn't  have  an  agreed 
upon  VV&A  process  but  23  Navy  systems  including  ITEMS  IAS  have  been  V&Ved. 

Mr.  Hartling  indicated  that  the  Navy’s  M&S  Master  Plan  sets  up  a  "virtual" 
organization  to  address  M&S  at  the  Department  of  the  Navy.  The  activities  of  the  DoN 
M&S  Management  Office  will  be  carried  out  by  the  Navy  M&S  Policy  and 
Coordination  Group  and  the  Marine  Corps  M&S  Policy  Coordination  Group.  Mr. 
Hartling  verified  that  the  current  Marine  Corps  accreditation  is  not  tied  to  V&V. 

The  Navy  M&S  library  currently  contains  600  entries.  This  library  contains  no  VV&A 
or  CM  information.  It  also  contains  many  models  and  simulations  which  are  out  of  data 
and  no  longer  used.  Mr.  Hartling  indicated  that  conceptual  models  of  existing  models 
will  be  built.  These  will  include  descriptors  to  record  user's  experience  of  use  with 
these  models.  The  Navy  will  perform  centralized  control  by  accepting  V&V 
documentation  of  M&S  into  the  library  but  the  V&V  will  be  executed  in  a  decentralized 
manner. 

(9)  Report  on  RAND  VV&A  Primer  Progress:  Bruce  Bennett,  RAND 

Mr.  Bennett  observed  that  M&S  conceptualization  and  validation  are  unique  hallenges 
in  the  military  operations  arena.  In  military  operations  M&S  we  simulate  qualitative 
factors  such  as  human  behavior.  These  qualitative  factors  are  difficult  to  validate  and 
as  a  result,  validation  is  often  incomplete.  The  burden  of  validation  shifts  from  the 
developer  to  the  application  user.  To  do  proper  validation,  we  must  concentrate  on  the 
processes  in  the  M&S  and  not  just  look  at  results.  We  typically  resort  to  doing 
"invalidation"  of  M&Ss  by  just  examining  results. 

Mr.  Bennett  indicated  there  were  two  distinct  stages  to  VV&A-preliminary 
accreditation  (planning)  and  final  accreditation.  Mr.  Hartling  noted  that  this  was 
especially  applicable  to  DIS  exercises  where  it  is  impossible  to  accredit  the  components 
up  front. 

Howard  Haecker  observed  that  historically,  the  user  of  a  model  will  change  the  data 
until  the  model  result  comes  out  right.  Mr.  Bennett  stated  that  he  has  seen  changes  to 
the  model  just  as  often. 
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Another  key  point  of  Mr.  Bennett's  presentation  was  that  historical  cases  have  limited 
value  in  the  W&A  of  military  operations  M&S.  This  is  the  result  of  constant  changes 
in  both  doctrine  and  technical  data. 

The  question  was  raised  as  to  how  all  of  the  guidelines,  policies,  and  procedures 
mentioned  to  that  point  related.  The  following  breakdown  was  suggested: 


Document/Models,  etc. 

DMSO  VV&A  TWG 

M&S  VV&A  Primer  (RAND) 


IPL  94-2  VV&A  of  Distributed  Simulations 
DS  W&A  Implementation  Guideline 

DS  VV&A  Methodology  Handbook 
Appendix  I:  Data  Consistency 
Appendix  II:  Algorithm  Consistency 
Appendix  III:  Tools 

DIS  VV&A  WG 

DIS  Recommended  Practices 


IDEFO  Model  Specification  for 
DIS  VV&A 

DRTWG  Data  VV&C  Task  Force 
Data  VV&C  Quality  Profile 

Guidelines  for  W&C  for  data  producers 

Guidelines  for  VV&C  for  data  users 


Authorized  data  sources 

IDEFO  models  for  data 
VV&C  (producers  and  users) 

DRTWG 

Directories  for  databases,  M&S,  and 
authoritative  data  sources,  and  DIS 
exercises 

Taxonomies  for  the  directories 

Note:  The  DS  VV&A  Implementation  Guide 
and  DIS  Recommended  Practices  documents 
may  be  combined. 


Intended  Use 

Reference  for  novice  application  sponsor,  ~  40 
pages,  pictures  and  graphics 

Guidance  for  VV&A  doers  and  M&S  developers 

For  technical  managers  of  M&S  development 

Guidance  for  VV&A  practitioners,  contains 
lessons  learned 

Reference  materials  for  W&A  agent 
Terminology  and  process  definition 

Reference  for  data  user  and  producer 

e.g.,  AMSSA,  DIA,  DMA 

Users:  e.g.,  data  centers  such  as  TRAC,  ARMS, 
CENTCOM's  CFDB,  J  8’s  OASIS 

Reference  for  M&S  application  developer 

data  producers  and  users 

For  use  throughout  M&S  community 

Users  of  directories 
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Discussion  of  morning  topics:  Mark  Ralston,  AMSAA 

The  goals  of  the  VV&C  Subgroup  as  defined  in  prior  meetings  are  broken  into  three 
tasks* 

Task  1:  Develop  guidelines  for  non-DIS  user  VV&C 
Task  2:  Develop  guidelines  for  DIS  user  VV&C 
Task  3  :  Develop  guidelines  for  producer  VV&C 

The  consensus  in  the  group  was  that  Task  2  should  use  the  results  of  the  DMSO- 
sponsored  effort,  VV&A  for  DS,  which  is  working  with  the  DIS  VV&A  WG  on  an 
IDEFO  model  for  DIS  VV&A/C.  The  group  also  agreed  that  Task  1  should  look  at  the 
applicability  of  guidelines  developed  under  these  efforts  and  should  begin  m  March  1995, 
complete  in  FY  95  and  be  funded  by  DMSO.  The  group  agreed  that  Task  3  should  begin 
as  soon  as  possible  with  DMSO  funding. 

Task  1  was  broken  down  into  the  following  subtasks  with  suggested  funding  levels  and 
durations: 

Subtask  1:  Decide  on  scope  .  , .  _ 

Subtask  2’  Develop  IDEFO  models  of  the  current  practices  used  in  DoD 

components,  DMSO  funding  =  $350K,  duration  =  2  months  /component. 
Subtask  3:  Develop  an  integrated  IDEFO  model,  DMSO  funding  =  $50K,  duration  - 
6  months 

Subtask  4:  Pilot  studies,  deferred  until  FY  96. 

The  following  personnel  were  identified  as  component  points  of  contact  for  the  Subtask  1 
development  of  current  practices  models: 

a  r  i  /r _ 1.  n 


Army  —  Mark  Ralston 

Navy  —  Bob  Hartling 

Marine  Corps  —  vacant 

Air  Force  —  vacant 

OSD  —  vacant  .  t  _  _ 

jCS  _  vacant  (Mike  Hopkins  recommended  GCCS  with  Cozy  Baily  as  a 

point  of  contact) 

If  JCS  and  Marine  Corps  are  both  used,  then  this  will  require  an  additional  $50K.  Lt  Col 
Denny  Lester  agreed  to  lead  Task  1. 

Task  3:  a  DMSO  funding  level  of  $400  was  suggested  for  Task  3  and  there  is  no  leader 
for  this  task  (Lt  Col  Barker  tentatively  volunteered  and  then  withdrew).  Suggested 
producers  to  participate  include  DMA  (POC:  David  >Danko  (they  have  IDEFO  as-be 
model);  DIA:  POC  Dr.  Guenther;  NAVOCEANO:  POC  Eleanor  Schroeder  Howard 
Haecker  suggested  that  the  Battlefield  Environmental  Directorate  at  WSMR  be  included. 

Lt  Col  Barker  questioned  the  value  of  modeling  current  practices  for  VV&C  since  they 
are  not  formally  documented.  Iris  Kameny  responded  that  this  would  provide  the 
advantage  of  having  current  best  practices  to  work  from  when  developing  proposed 
guidelines. 

Working  session  on  Database  Quality  Profile:  Jeff  Rothenberg,  RAND 

Jeff  Rothenberg  distributed  his  12  October  draft  of  "A  Data  Quality  Profile  for  VV&C  of 
data  to  be  Used  in  Modeling"  and  provided  an  overview  of  the  paper.  Data  quality,  as 
defined  by  Mr.  Rothenberg,  is  the  suitability  of  data  for  a  consumer’s  purpose. does 
not  limit  the  definition  to  the  factors  described  in  DoD  8320.1-M-2  or  DIGEST  (DMA), 
such  as  timeliness,  accuracy,  relevancy,  etc..  The  data  quality  profile  suggeste  y 
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Rothenberg  encompasses  three  levels--database,  data  element,  and  instance  data.  The 
data  quality  profile  contains  meta-data  needed  both  to  allow  verification  and  to  record  the 
results  of  verification.  Mr.  Rothenberg  suggested  that  a  data  model  be  developed  to 
understand  the  meta-data  involved  in  a  data  quality  profile.  The  group  had  the  following 
observations  and  comments  about  the  data  quality  profile. 

Iris  Kameny  suggested  that  Mr.  Rothenberg  assist  Ms.  Solick  to  include  the  quality 
profile  in  the  data  consistency  portion  of  the  DIS  VV&A/VV&C  model. 

Miranda  Stem  indicated  that  the  DoD  8320  series  of  documents  (which  address  data 
quality)  are  being  updated  and  she  will  send  Chien  Huo  a  list  of  the  8320  documents  and 
who  is  doing  what. 

Allen  Hess  stated  that  we  can  not  anticipate  all  of  the  quality  meta-data  that  could  be 
needed,  but  suggested  that  we  strive  to  set  a  minimal  list. 

Lt  Col  Barker  stated  that  he  does  not  see  the  need  to  separate  producer's  and  consumer's 
views  when  characterizing  the  data  VV&C  process.  He  said  they  are  spending  three 
years  and  $25  million  to  change  the  behavior  of  the  collection  community.  They  are 
looking  for  an  80/20  solution  but  hands  on  people  have  a  problem  with  metadata.  There 
is  measured  data  and  calculated  data,  and  a  need  to  be  practical  about  the  amount  of 
metadata.  However,  capturing  the  data  generation  process  is  very  important  and  includes 
the  modification  and  propagation  of  data. 

Jim  Augins  raised  the  concern  about  metadata  about  metadata  and  how  many  levels  of 
recursion  were  needed?  (Jeff  Rothenberg  thought  just  one,  to  include  metadata  about  the 
metadata). 

Howard  Haecker  raised  concerns  about  the  quantity  of  meta-data  that  will  be  required. 

He  stated  that  it  is  nearly  impossible  to  capture  all  of  the  knowledge  about  a  data  element. 
He  suggested  that  we  need  information  about  the  quality  of  user  s  decisions  with  regards 
to  filling  data  voids  or  making  modifications  to  data.  Mr.  Haecker  sees  void 
management"  as  one  of  the  areas  of  biggest  payback  for  quality  improvement.  Lt  Col 
Barker  stated  that  those  who  fill  voids  in  data  bear  the  responsibility  for  providing 
feedback  to  the  data  producers.  Bob  Hartling  suggested  that  this  VV&C  information  be 
integrated  into  VV&C  repositories. 

Mr.  Haecker  is  also  concerned  that  we  quantify  the  cost  of  data  quality.  Mr.  Rothenberg 
indicated  that  we  also  need  to  capture  the  cost  of  not  performing  data  quality  checks,  but 
that  is  difficult  to  quantify.  Bob  Hartling  stated  that  one  cost  is  the  overbuilding  of 
systems  to  compensate  for  lack  of  confidence  in  data.  Another  cost  is  the  duplication  of 
VV&C  by  users  when  it  is  not  done  by  producers. 

Linda  Calvert  recommended  that  we  draw  from  current  best  practices  to  document  the 
current  baseline  for  VV&C.  Mr.  Rothenberg  recommended  that  a  pilot  be  done  in 
concert  with  the  producer  W&C  guideline  development.  Mike  Hopkins  offered  that 
CENTCOM’s  Data  Quality  Engineering  program  is  a  good  candidate  for  documenting 
current  data  quality  practices.  He  also  added  that  current  VV&C  practices  are  being 
documented  as  part  of  the  Authoritative  Data  Sources  task. 

Someone  said  that  with  respect  to  data  generation,  management  and  use:  each  and  every 
community  needs  to  accept  equal  responsibility  for  data  quality  and  if  data 
analysis/VV&C  are  paid  for  by  the  government,  then  the  results  need  to  be  fed  back  for 
reuse. 
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The  group  consensus  was  on  the  following  approach: 

(a)  Identify  current  VV&C  practices  as  part  of  the  Authoritative  Data  Sources  task 

(b)  Pick  some  of  the  current  processes  for  IDEFO  modeling  of  VV&C  practices 

(c)  Use  one  or  more  of  these  as  data  quality  pilot  studies. 

Lt  Col  Danny  Lester  recommended  that  we  plan  for  more  long-term  projects  such  as  the 

Joint  Advanced  Distributed  Simulation  (JADS)  project.  Mike  Hopkins  suggested  GCCS 

also  be  included. 

Suggested  Actions: 

(1)  Communicate  with  component  M&S  organizations  on  supporting  tasks  1  and  2 

(2)  Investigate  possibility  of  DISA  support  for  component  surveys  and  pilot  studies 

(3)  Investigate  DISA  efforts  in  V&V  tools,  and  in  distributed  access  and  use 

(4)  Need  to  better  define  categories  of  data  quality  and  make  the  metadata  machine 
readable 

(5)  Suggestion  that  terms  such  as  clarity,  flexibility  etc.  that  are  qualitative  be  re¬ 
examined  and  that  we  stick  to  quantitative  terms 

Steps  Toward  Data  Quality: 

(1)  Find  out  what  DISA/JIEO  is  doing  about  data  quality  with  respect  to  Automated 
Resource  Management  Systems 

(2)  Work  with  Authoritative  Data  Sources  survey  to  follow  up  on  what  people  are 
doing,  e.g..  Air  Force  Log  Command  uploads  data  from  the  bases,  verifies  and 
highlights  errors  and  waits  for  the  base  to  fix  the  data 

(3)  Get  support  by  asking  study  directors  how  much  it  costs  to  VV&C  data  and  ask 
the  decisionmakers  how  much  overkill  is  there  to  compensate  for  bad  or  low 
quality  data 

Summary  of  Data  Quality  Profile  Issues: 

(1)  Metadata  about  metadata  with  respect  to  quality:  one  level  of  recursion 

(2)  Concern  with  volume  of  metadata 

(3)  Data  modification  or  algorithm  modification  by  M&S  users:  needs  to  be 
captured  (base  on  case  and  sensitivity  analysis) 

(4)  Next  version  of  data  quality  profile  paper  baseline:  include  current  data  centers 
and  recognized  needs  as  far  as  lessons  learned  about  data  quality  (requirements, 
tools,  etc.) 

(5)  Difficulty  and  need  to  address  data  voids  (missing  data)  in  data  collection 

(6)  Need  to  add  at  database  level,  information  on  data  source(s) 

(7)  Usage  V&V  needs  to  be  integrated  into  overall  V&V;  not  enough  to  find  data 
errors,  their  existence  needs  to  be  maintained  in  the  repository.  Question  about 
how  to  handle  VV&C  errors,  should  the  process  require  feedback  to  the 

User  Repository 

Producer - >Data  Center - >  user  of  M&S  could  make  data 

„  changes  on  basis  of  finding 

Repository<  Repository  errors  or  needs  of  application 

and  those  changes  do  not  feed 
back  to  the  data  center 

producer  for  change?  if  so,  potential  data  errors  need  to  be  marked  in  interim  so 
user  is  aware  of  them  (CENTCOM  CFDB  is  not  doing  this  now). 
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12  Report  on  Authoritative  Data  Sources  status  and  plans:  Bill  Dunn,  AMSMO  and  Mike 
Hopkins,  CSC  (CENTCOM) 

Mr.  Dunn  identified  the  following  subtasks  for  the  Authoritative  Data  Sources  (ADS) 
subgroup  and  reported  on  their  status: 

Subtask  1 :  Finalize  the  taxonomy  of  M&S  data.  Currently  the  taxonomy  proposed  by 
Haecker/Swindell  is  being  used.  Dave  Danko  has  some  concerns  in  the  areas  of 
"environment"  and  "geopolitical"  and  will  work  with  the  members  of  the  subgroup. 

Subtask  2:  Develop  a  data  model  for  the  ADS  directory.  A  proposal  has  been  submitted 
to  DMSO  which  Dr.  Huo  has  forwarded  for  funding.  This  data  will  be  integrated  with 
the  existing  M&S  Database  Directory  data  model. 

Subtask  3:  Populate  the  ADS  directory.  This  is  currently  underway  and  is  available  on 
the  Internet  World  Wide  Web  (at  hhtp://trp.ida.org/msdb.html).  Currently  there  are  70 
ADSs  and  data  centers  identified  in  the  directory.  Mike  Hopkins  asked  that  DMSO  take 
over  maintenance  of  the  directory.  Jeff  Rothenberg  suggested  that  the  responsibility  for 
maintaining  the  information  be  distributed  so  that  individual  sites  can  link  their  data 
element  dictionaries  to  the  directory  through  the  World  Wide  Web.  An  area  of  concern 
here  is  the  links  between  unclassified  and  classified  networks.  Roy  Scrudder  suggested 
that  JDBE  could  translate  the  current  directory  from  its  current  storage  as  a  WordPerfect 
file  to  a  xBase  database.  Then  user's  could  use  whatever  tools  they  prefer  to  access  and 
search  the  database.  The  group  agreed  to  this  approach. 

Subtask  4:  Identify  responsibilities  of  ADSs,  data  centers,  and  users.  This  will  hopefully 
come  from  the  VV&C  pilot  studies.  Iris  Kameny  stated  that  this  be  a  "should-be"  set  of 
recommended  responsibilities,  not  just  "as-is."  The  responsibilities  should  be  expanded 
to  include  release  authority.  Ms.  Kameny  feels  we  should  identify  the  current  shortfalls 
and  needs  to  the  OSD  level  through  DMSO. 

Subtask  5:  Determine  classified  data  exchange  procedures  and  release  authority.  This 
will  be  moved  to  a  new  Data  Security  Requirements  Task  Force.  Mike  Hopkins 
identified  the  need  to  address  the  electronic  interchange  of  data  between  data  centers  and 
ADSs.  He  feels  the  "need  to  know"  restrictions  are  workable. 
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12.1  AGENDA 

THURSDAY,  NOVEMBER  3, 1994 

0800  -  08 1 5  Introductions  and  Administrative  Remarks  -  Bill  Dunn  and  Mike  Hopkins 
0815  - 1000  Finalization  of  Taxonomy  for  Data  Sources  Directory  -  Bill  Dunn 
1000-1015  Break 

1015  - 1 100  Update  on  Data  Sources  Directory  Survey  -  Mike  Hopkins 

1100-  1145  Demonstration  of  Data  Sources  Directory  with  World  Wide  Web  -  Mike  Hopkins 
(Note:  this  was  cancelled  due  to  being  demonstrated  the  day  before) 

1 145  -  1230  Discuss  subgroup  taskings  -  Iris 

1230-  1330  Lunch 

1330  -  1600  Follow-up  discussion  on  M&S  Taxonomy 
1600  -  Wrap-up  &  Adjourned 


AUTHORITATIVE  DATA  SOURCES  SUBGROUP 
MEETING  AT  USCENTCOM 


-152- 


11 

1 

£ 

p 

O 

00 

eg 

£ 

o 

1 

O 

CO  cJ 

£  & 
T3  X 

£ 

c3 

o 

o 

e 

0) 

> 

o 

c 

<D 

CU 

® 

<w 

a 

<u 

q 

d 

.2  On 

S-4 

q 

op 

c 

o 

,p7> 

® 

*C/3  f-H 

6  § 

(§)  s/5 
>>© 

<u 

o 

C3 

l* 

® 

d 

u 

o 

o 

® 

d 

E 

-o 

© 

G 

3 

T3 

X 

o 

o 

© 

W5 

C 

>> 

<0 

o 

m 

T3 

E 

15 

JU 

”3 

X) 

o 

go 

Me 

cS  on 

jD 

TH 

O 

o 

<u 

t: 

o 

o 

X 

O 

X 

c 

rt 

HD 

E 

£ 

o- 

o 

X 

£ 

^  c  ; 
«  si1 

§®  ff 

®  g  § 


\  r?  2°  oo  ©  o  £ 

»  cn  <n  >A  ^  (sj  oo 
.  oo  C\  XI  oo  in  cs 
j  cs  vo  n,  vo  in  oo 

;PPZPZco 
5  o  o  on  —  co  — 
)  StD  0.P  SS 


o  oo  3!  Tf  Cr 
m  ro  o®  oo 
cs  cn  co  JJ; 

t  ^  c*  *?  <?  *? 

oo  *01  10  ^  P  *0) 
S  00  o  CN 
c\  <n  on  'O  co  'y° 

Z  PZ  53  Z  eg 
co  O  co  o  co  o 
Q^QC^QC: 


£§8 

rSs 

«n  °®  oo 
<N  £*  vo 

Cl  00  C-N 

zPz 

CO  —  CO 

QSSQ 


O  ^  rtf" 

VO  3  rn  cn 
OOcoS 

00  CO  r-  ri 
CNONOkl 

C\  co  no  ^ 

co  co  co  Z 
O  O  O  00 
^  ^  ^  Q 


o\  as  tt  3  ^  oo  oo 

2  °o  JQ  S  5  o 

tt  <^c?r?°?°? 

r-  oo  r-  rP  Tt  ^ 

On  ki  WO  On  cs  00  uo 
no  cs  NO  CM  VO  uo 

co  Z  ^co  Z  CO  Z 

°  CO  O  O  oo  CO 
q  tt  r-  q  on  q 


icjb^oooo^' 

\  5^  CO  CO  I 
-  ^  ON  <?  CO  ^  < 

)  ^  Er  P  2?  1 

-,  CC'  m  O  rx]  ^  i 

:  Pz  Pz  P; 

5  ®  CO  o  CO  o  i 
1  C^P  wQ  wi 


CO  ’ — 1  ^ 

0O  0Q 
OO  CO  ^ 
Tf  CO  ^ 

I  I  I* 

for-ri 
ON  ok) 
CO  NO  ^ 

'onZ 
— *  ©  co 

,C.^P 


Q  8 

¥  g 

U  ffl 
OS  U 


£ 

O 

9  I 

00  CO 


o 

OPS 
52  Z  Eg 

123 


O  £3 

os  2 


UAJ 


Eleanor  Schroeder  NAVOCEANO  (601)688-4639  (601)688-5502  eleanor@msis.dmso.mi 

DSN  485-4639  DSN  485-5502 


-153- 


12.3  MAIN  OBJECTIVES  OF  MEETING 

Most  of  the  meeting  was  devoted  to  further  development  of  the  Taxonomy  for  the  Data  Sources 
Directory.  The  Draft  M&S  Data  Categories  (initially  distributed  to  members  in  June)  was 
reviewed  and  suggestions  for  changes  were  made.  Another  objective  of  the  meeting  was  to 
address  the  taskings  of  this  subgroup  as  determined  by  I/DB  Task  Force  and  Subgroup  chairs  and 
co-chairs.  A  third  objective  was  to  provide  a  status  report  on  the  Data  Sources  Directory  Survey. 
All  three  objectives  were  well  met. 
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12.4  MEETING  NOTES 

A.  Taxonomy  for  Data  Sources  Directory 

Discussion  on  this  issue  took  up  most  of  the  meeting.  Some  of  the  discussion  occurred  in 
the  morning  session  but  had  to  be  temporarily  tabled  so  that  the  other  issues  could  be 
addressed  before  people  had  to  catch  flights  out.  An  afternoon  session  was  held  to 
continue  the  discussion. 

It  should  be  noted  the  meeting  tended  to  jump  around  the  top  level  categories.  In  the 
interest  of  efficiency,  the  notes  will  not  reflect  the  discontinuities  in  the  thought 
processes.  The  appendix  to  this  lists  what  the  suggested  categories  (and  in  some  cases, 
subcategories)  are. 

The  purpose  of  this  issue  is  to  construct  a  taxonomy  of  data  that  would  break  the 
authoritative  data  sources  into  more  manageable  pieces.  The  Army's  data  model  was 
used  as  a  basis  with  input  from  RAND. 

It  was  agreed  that  the  top  level  of  the  taxonomy  should  consist  of  generic  categories. 
Based  on  that  premise,  discussion  ensued  as  to  why  EQUIPMENT  CHARACTERISTICS 
and  EQUIPMENT  PERFORMANCE  show  up  at  the  top  level  instead  of  a  category 
called  EQUIPMENT.  One  of  the  AMSMO  representatives  explained  that  the  army 
selected  separate  categories  since  the  characteristic  portion  was  to  include  data  on  the 
equipment  that  would  be  considered  static  (e.g.,  shipping  information)  while  the 
performance  portion  was  to  include  data  that  would  be  considered  dynamic  (e.g.  speed  of 
vehicle  when  in  combat).  Different  subject  matter  experts  (SMEs)  are  needed  for  these 
two  categories.  A  suggestion  was  offered  that  would  list  EQUIPMENT  as  the  main 
category  with  LOGISTICS,  ENGINEERING  SPECIFICATIONS,  and  PERFORMANCE 
AND  FUNCTIONAL  DESCRIPTIONS  as  the  second  level.  This  did  not  satisfy  the 
Army  representatives  at  the  meeting.  It  was  finally  decided  to  list  EQUIPMENT  as  the 
main  category.  EQUIPMENT  CHARACTERISTICS  and  EQUIPMENT 
PERFORMANCE  would  be  listed  as  level  2  categories. 

This  led  into  a  suggestion  that  whatever  was  accomplished  at  this  meeting  would  be 
released  to  the  community  as  either  a  Beta  test  version  or  as  a  Version  1.0.  The  users  of 
this  taxonomy  could  then  provide  their  input  on  how  well  it  really  works  and 
modifications  could  be  made  on  the  taxonomy  based  on  that  input.  It  was  agreed  that  this 
was  a  good  idea. 

COMBAT  SUPPORT  SERVICES  was  addressed  next.  It  was  noted  that  oftentimes  the 
joint  arena  will  adopt  service's  "label"  and  apply  that  label  across  the  board.  Combat 
Support  Services  is  a  term  used  predominantly  by  the  Army.  It  was  agreed  to  rename  the 
category  SUPPORT  SERVICES.  Level  2  categories  were  renamed  to  LOGISTICS, 
MEDICAL,  and  PERSONNEL.  It  was  also  at  this  point  that  FINANCE  was  determined 
to  be  a  more  generic  term  than  COST,  and  thus  was  elected  to  be  the  top  level  category. 

ENVIRONMENT  and  GEO-POLITICAL  were  the  next  areas  of  discussion.  The  DMA 
representative  desired  that  the  GEO  portion  of  GEO-POLITICAL  be  removed.  The 
BORDERS  and  CITIES/TOWNS  subcategory  listings  belonged  under  the  TERRAIN 

level  2  category  of  the  ENVIRONMENT  ("borders"  fall  under  boundaries  and 

"cities/towns”  under  "population").  Since  DMA  is  the  recognized  authority  on  this,  this 
modification  was  included.  The  DMA  representative  offered  two  level  3  breakdowns  for 
the  TERRAIN.  One  was  obtained  when  DMA  approached  military  map  producers  in 
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NATO;  the  other  was  obtained  when  DMA  worked  with  users.  It  was  opted  to  go  with 
the  user  alternative.  A  question  was  raised  on  whether  this  is  in  line  with  what  Jack 
Teller’s  (DMA)  group  was  doing.  It  was  stated  that  the  Teller  group  was  using  the 
military  map  producer  alternative  as  its  starting  point.  A  concern  was  raised  on  whether 
use  of  the  Digital  Topographic  Data  categories  in  DMA's  "Digitizing  The  Future"  book 
were  being  addressed  by  any  of  the  groups.  The  DMA  representative  plans  to  coordinate 
with  the  Teller  group  before  finalizing  the  TERRAIN  subcategory  listing. 

An  issue  arose  early  in  the  discussion  on  electronic  counter-measure  effects.  It  was 
decided  that  a  level  2  category  under  ENVIRONMENT  would  be  created  called  EM  and 
that  this  category  would  contain  information  such  as  that. 

The  Navy  had  previously  submitted  its  suggested  changes  to  the  OCEANOGRAPHIC 
and  NAVIGATION  categories.  These  are  incorporated  in  the  Appendix  listing.  The 
SPACE/UPPER  ATMOSPHERE  category  still  needs  to  be  subcategorized.  This  will  be 
worked  on  before  the  next  meeting. 

TTP  COGNITIVE  was  elected  to  remain  as  is. 

The  SCENARIO  category  caused  some  discussion.  A  clearer  definition  of  scenario  was 
desired  by  some  of  the  members  before  subcategories  could  be  discussed.  Bob  Hartling 
and  Cathy  Corland  will  attempt  to  tighten  the  definition. 

Chien  Huo  then  asked  if  the  categories  that  are  listed  in  the  DoD  Modeling  and 
Simulation  Master  Plan  should  be  used  for  the  development  of  the  Data  Sources 
Directory  Taxonomy.  Iris  Kameny  said  that  her  interpretation  of  the  contents  of  the 
Master  Plan  was  that  those  are  the  main  areas  that  DMSO  needs  to  address  and  that  the 
list  was  not  all-inclusive.  Therefore,  those  categories  should  be  and  are  included  in  the 
developed  taxonomy. 

It  was  decided  that  no  subject  matter  experts  for  UNIT  PERFORMANCE  were  present  at 
the  meeting,  so  discussion  on  that  category  was  tabled  to  the  next  meeting.  Cathy 
Corland  will  talk  to  people  at  TRAC  to  get  a  clearer  understanding  of  this  category. 

The  TEST  category  was  renamed  to  TEST  RESULTS.  It  was  felt  that  this  title  better 
described  the  contents  of  this  category.  Some  discussion  occurred  on  exactly  what  was 
meant  by  MEASURED  vice  SCIENCE  AND  TECHNICAL.  An  example  for 
MEASURED  was  the  utilization  of  an  actual  tank  in  tests  to  determine  if  it  meets  certain 
performance  levels.  SCIENCE  and  TECHNICAL  was  to  cover  those  tests  that  used  a 
simulator  to  determine  whether  certain  performance  levels  are  met.  The  results  of  that 
discussion  led  to  the  level  2  categories  being  renamed  to  MEASURED  and 
ESTIMATED.  It  should  be  noted  that  the  ESTIMATED  subcategory  title  may  be 
changed. 

Under  FORCE  DESCRIPTION,  the  group  decided  that  an  enumerated  listing  of  what  the 
various  services  and  the  Intell  community  use  would  be  provided.  Representatives  of  the 
various  areas  provided  input  needed. 

HUMAN  FACTORS  concerns  the  "man  in  the  loop"  factors.  In  the  DoD  Modeling  and 
Simulation  Master  Plan,  categories  were  listed  under  "Behavioral  Categories"  (see 
footnote  14  on  page  4-12).  These  categories  were  suggested  for  use  as  level  2  categories 
under  HUMAN  FACTORS.  One  of  the  Army  representatives  preferred  the  use  of 
ENVIRONMENT,  EQUIPMENT,  and  OTHER  for  level  2  categories,  feeling  that  these 
were  more  in  line  with  the  definition.  A  "final"  decision  will  be  made  at  the  next 
meeting. 
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B.  Status  of  the  Data  Sources  Directory  Survey 

A  new  directory  was  distributed  at  the  meeting.  Revisions  are  requested  as  necessary. 
Please  notify  Mike  Hopkins  if  you  have  any  changes. 

We  are  awaiting  more  information  from  NASA.  Also  needed  is  information  from  DIA 
and  the  Navy  and  Marine  Corps  Logistics  arena. 

Mike  Hopkins  is  coordinating  with  Pete  Valentine  on  selecting  a  DBMS  for  this 
directory.  Currently,  ACCESS  is  the  DBMS  of  choice. 

The  long  range  goal  is  to  go  to  the  people  identified  as  POCs  and  obtain  more 
information  on  the  major  data  files,  e.g.,  data  element  dictionaries  (DED).  This  provoked 
major  discussion  on  releasability  issues.  It  was  finally  decided  that  the  data  file 
information  would  be  limited  to  distribution  within  the  DoD  only  until  releasability  issues 
for  primarily  the  Navy  and  the  Intell  community  can  be  addressed  and  resolved.  A 
supplemental  form  will  be  designed  for  the  data  file  information  based  on  what  FGDC 
used  to  obtain  information  for  spatial  metadata. 

Discussion  also  ensued  as  to  what  data  should  be  included  in  this  directory.  At  one  point, 
it  was  to  contain  only  the  data  sources/centers  considered  to  be  the  authority  for  that  data. 
However,  since  the  term  "authoritative  data  source"  was  not  clearly  defined,  it  was 
decided  to  accept  all  inputs  and  not  limit  it  to  authorities  in  the  various  area.  It  was 
pointed  out  that  this  could  be  a  large  volume  of  information  and  that  some  sort  of 
constraint  should  be  made.  The  counterpoint  to  this  was  that  multiple  agencies  may  think 
they  are  the  only  authoritative  data  source/center  or  that  there  could  be  cases  where  an 
agency  may  be  the  only  source  for  a  certain  type  of  data  but  was  unaware  of  that.  This 
data  call  could  then  ferret  out  those  centers  for  use  by  the  modeling  and  simulation 
community. 

C.  Taskings  of  the  Authoritative  Data  Sources  Subgroup 

The  purpose  of  this  subgroup  is  to  enable  M&S  users  and/or  developers  to  quickly  know 
where  to  go  for  valid,  timely,  VV&Ced  (quality/documented),  authorized  data  that  is 
managed  according  to  the  guidelines  and  for  those  users  to  receive  service  according  to 
the  guidelines.  Five  subtasks  were  listed  at  one  time  for  this  subgroup: 

(1)  Finalize  taxonomy  for  authoritative  data  sources 

(2)  Develop  a  data  model  for  Authoritative  Data  Sources  and  implement  and 
manage  in  the  DMSO  repository. 

(3)  Populate  this  directory  through  Component  representatives  and  by  an  OSD 
survey. 

(4)  Identify  the  responsibilities  for  data  centers,  authoritative  data  sources  and 
users. 

(5)  Define  how  classified  data  centers  can  exchange  data  with  other  centers  and 
release  data  to  users.  Address  data  aggregation  and  release  authority  issues. 

Subtask  (1)  Will  continue  to  be  addressed  and  agreed  to  among  the  subgroup  members. 

Subtask  (4)  It  was  decided  that  the  result  of  Subtask  4  would  be  a  recommendation  to 
DMSO  on  what  the  responsibilities  should  be.  Each  of  the  services  would  be  contacted 
to  obtain  their  viewpoint.  LEVEL  OF  EFFORT:  not  determined  at  this  time 
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Subtask  (5)  Has  since  become  an  issue  for  the  newly  formed  Security  Subgroup  which  ill 
be  meeting  on  December  14, 1994  at  IDA.  Subtasks  (2)  and  (3)  have  been  reworded  as 
follows: 

(2)  Develop  a  Data  Source  Model  for  the  Authoritative  Data  Source  Directory. 
PURPOSE:  (1)  to  enable  the  M&S  community  to  quickly  locate  possible 
sources  of  data  and  obtain  a  general  understanding  of  the  types  of  data  for 
further  research  and  reuse;  (2)  to  facilitate  the  submission  of  data  elements  for 
candidate  data  standards;  and  (3)  to  facilitate  the  linking  of  databases. 

GOAL:  to  produce  a  data  source  data  model  that  will  provide  the  architecture 
for  obtaining  and  populating  an  Authoritative  Data  Source  Directory. 

LEVEL  OF  EFFORT:  12  person  months 

(3)  Implement,  populate,  manage,  and  maintain  a  data  source  Directory  in  the 
DMSO  repository  as  modeled. 

PURPOSE:  to  provide  the  M&S  community  with  a  populated  directory  of 
possible  data  sources/centers. 

GOAL:  populate  the  data  source  directory  as  modeled  in  subtask  2. 

LEVEL  OF  EFFORT:  12  person  months  plus  4  months  per  year  maintenance 

D.  Other  Business 

Bill  Dunn  said  that  the  Army  Modeling  and  Simulation  Management  Office  has 
undergone  a  restructuring.  As  a  result  of  this,  Lana  McGlynn  has  assumed  the  duties  of 
the  functional  side  for  data  and  would  therefore  be  representing  AMSMO  in  future 
meetings.  Bill  tendered  his  resignation  as  co-chair  of  this  subgroup  and  nominated  Lana 
as  his  replacement.  Chien  Huo  will  check  with  the  DMSO  for  confirmation.  We  thank 
Bill  for  his  dedication  to  this  task  and  for  his  leadership  and  organizational  skills. 

The  NEXT  MEETING  is  scheduled  for  the  morning  of  December  15, 1994  at  IDA. 
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12.5  ACTION  ITEMS 

A.  Taxonomy 
Steve  Boyd: 

ENVIRONMENT  Category  -  SPACE/UPPER  ATMOSPHERE  breakdown; 
coordinate  with  Lana  McGlynn  (Army  -  AMSMO)  and  LCDR  George 
Flax  (Navy-  SPAWAR) 

Cathy  Corland: 

SCENARIO  Category  -  "tighten"  definition;  coordinate  with  Bob  Hartling 
TEST  RESULTS  Category  -  definitions  and  level  2  and  level  3  breakdowns 
UNIT  PERFORMANCE  Category  -  definitions  and  level  2  breakdown 

pave  Danko: 

ENVIRONMENT  Category  -  TERRAIN  breakdown  and  definitions 
ENVIRONMENT  Category  -  NAVIGATION  breakdown;  coordinate  with 
Eleanor  Schroeder  and  Lana  McGlynn 

Bob  Hartling: 

SCENARIO  Category  -  "tighten"  definition;  coordinate  with  Cathy  Corland 

Mike  Hopkins: 

FORCE  DESCRIPTION  Category  -  Identify  Navy's  term  equivalent  to  TO&E, 
TO,  TE,  and  TA 

Lana  McGlynn: 

ENVIRONMENT  Category  -  NAVIGATION  breakdown;  coordinate  with  Dave 
Danko  and  Eleanor  Schroeder 

ENVIRONMENT  Category  -  SPACE/UPPER  ATMOSPHERE  breakdown; 
coordinate  with  Steve  Boyd  and  LCDR  Flax 
Eleanor  Schroeder: 

ENVIRONMENT  Category  -  OCEANOGRAPHIC  breakdown 
ENVIRONMENT  Category  -  NAVIGATION  breakdown;  coordinate  with  Dave 
Danko  and  Lana  McGlynn 

B.  Data  Source  Directory  Survey 

Dave  Danko:  Geate  a  supplemental  form  for  the  data  file  information 
Mike  Hopkins: 

(1)  Get  input  from  Navy  Logistics 

(2)  Coordinate  more  Army  Logistics  input  with  Lou  Fenis/Susie  Glick 

(3)  Coordinate  Marine  Corps  Logistics  input  with  MAJ  Steve  Zawitz 

(4)  Get  more  input  from  NASA 

(5)  Contact  new  potential  sources  such  as  US  Coast  Guard,  CAA,  MTMC,  OSD 
PA&E,  and  some  of  DOD's  MAGA  data  centers 

Chien  Huo:  Get  DIA  input 

ALL  OTHERS:  Review  latest  draft;  notify  Mike  Hopkins  of  changes,  if  any 

C.  Taskings 

Mike  Hopkins: 

( 1 )  Work  with  Iris  Kameny  on  approach  to  subtask  2 

(2)  Develop  strawman  for  subtask  4 

(3)  IAW  JDBEs  Gary  Lambert,  research  the  M&S  Data  Repository  design  model 

Iris  Kameny:  Work  with  Mike  Hopkins  on  approach  to  subtask  2.  Iris  is  concerned 

that  the  information  in  the  Authoritative  Data  Sources  data  model  will  overlap  so 
much  with  the  existing  Databases  Directory  Data  Model  that  there  isn't  a  need  for 
both  directories.  Mike,  Gary  and  Iris  will  examine  this  issue  and  make  a 
recommendation  to  the  Subgroup. 
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Cozy  Bailey:  Determine  whether  the  C2  Core  Data  Model  is  integrated  into 

the  DoD  Data  Model.  (This  arose  as  a  result  of  discussion  for  the  Complex  Data 
Task  Force  subtask  of  modeling  CFDB/MSDS  to  the  C2  Core  Model.) 


Chien  Huo:  Present  Lana  McGlynn's  nomination  as  co-chair  for  the  Authoritative 
Data  Sources  Subgroup  to  DMSO  for  confirmation 

IrisKameny: 

( 1 )  Add  Mike  Hopkins  and  Dave  Danko  to  Repository  Subgroup  s  mail  list 

(2)  Redraw  charts  IAW  new 
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12.6  APPENDICES 

A.  Suggested  Taxonomy  for  Data  Sources  Directory: 

1.  FINANCE: 

<subcategories  to  be  determined> 

2.  ENVIRONMENT: 

a.  Terrain 

1.  Boundaries 

2.  Elevation 

3.  Hydrography 

4.  Industry 

5.  Physiography 

6.  Population 

7.  Transportation 

8.  Utilities 

9.  Vegetation 

10.  Surface  Materials 

b.  Oceanographic 

1.  Acoustics 

2.  Bathymetry 

3.  Biologies 

4.  Geology 

5.  Gravity 

6.  Geomagnetics 

7.  Sea  Surface 

8.  Water  Column  &  Currents 

c.  Weather,  Obscurants  &  Man-Made  Conditions 

1.  Seasonal 

2.  Daily 

3.  Day/Night 

4.  Man-Made  Conditions  (e.g.  smoke) 

d.  Space/Upper  Atmosphere 
<subcategories  to  be  determined> 

e.  EM 

<subcategories  to  be  determined> 

f.  Navigation 

1.  Obstructions 

2.  Landmarks 

3.  Non-electronic 

4.  Inertial 

5.  Radio 

6.  Satellite 

3.  EQUIPMENT: 

a.  Equipment  Characteristics 

1.  Air  Vehicles 

2.  Land  Vehicles 

3.  Sea  Vehicles 

4.  Space  Vehicles 

5.  Monitors 

6.  Electronics 

7.  Sensors 

b.  Equipment  Performance 
1.  Air  Vehicles 
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2.  Land  Vehicles 

3.  Sea  Vehicles 

4.  Space  Vehicles 

5.  Missiles 

6.  Electronics 

7.  Sensors 

4.  FORCE  DESCRIPTION: 

Army:  TO&E’s  (Table  of  Operation  and  Equipment) 

Marine  Corps:  TO/TE  (Table  of  Organization/  Table  of  Equipment) 
Air  Force:  TA  (Table  of  Authorization) 

Navy:  <to  be  provided> 

Intell:  foreign 

5.  POLITICAL: 

a.  Demographics 

b.  Policy 

c.  Economics 

6.  HUMAN  FACTORS: 

a.  Sensory 

b.  Perception 

c.  Physical 

d.  Cognitive 

e.  Social 

f.  Emotional 

7.  SERVICE  SUPPORT: 

a.  Logistics 

b.  Medical 

c.  Personnel 

8.  SCENARIO 

<Subcategories  to  be  determined> 

9.  TEST  RESULTS: 

a.  Measured 

b.  Estimated 

10.  TTP  COGNITIVE: 

a.  Tactics 

b.  Operational 

c.  Doctrine 

d.  C3I 

11.  UNIT  PERFORMANCE: 

<subcategories  to  be  determined> 

12.  MISCELLANEOUS: 
a.  Data  Standards 
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13.1  AGENDA 


WEDNESDAY,  DECEMBER  14,  1994 


0830  -  0900 

0900-0930 
0930  - 1050 


1050-  1110 
1110- 1140 
1140-1210 
1210  - 1240 
1240-  1310 

1310-1340 
1340  -  1410 
1410-1430 
1430  -  1630 
1630-  1700 


Introduction:  Dr.  Chien  Huo  (DMSO) 

Ms.  Teresa  Lunt  (ARPA/CSTO) 

Needs  for  Data  Security  Requirements:  Ms.  Iris  Kameny  (RAND) 
Some  Specific  Needs  from  the  Services: 

1 .  Mr.  Howard  Haeker  (Army  TRAC) 

2.  LtCol  Dan  Hogg  (Joint  Staff) 

3.  Mr.  Mike  Hopkins  (CENTCOM) 

4.  Maj.  Steve  Zeswitz  (USMC) 

(presented  by  Steve  Galloway) 

5.  Ms.  Lana  McGlynn  (US  Army) 

6.  LCDR  Bruce  Stewart  (US  Navy) 

(presented  by  LCDR  Don  Hagerling) 

Break 

Data  Interoperation:  Dave  Gunning  (ARP A) 

Database  Security  Technology:  Mr.  Tom  Haigh  (SCC) 

Working  Lunch 

Data  Inference:  Dr.  Xiaolei  Qian  (SRI) 

(presented  by  Teresa  Lunt) 

Data  Aggregation:  Ms.  Catherine  Meadows  (NRL) 

Data  Integrity:  Ms.  LouAnna  Notargiacomo  (MITRE) 

Break 

Discussion 

Wrap-up:  Dr.  Chien  Huo  (DMSO) 

Ms.  Teresa  Lunt  (ARP A) 
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13.3  MAIN  OBJECTIVES  OF  MEETING 

This  was  the  first  meeting  of  the  Data  Security  Requirements  Task  Force  of  the  DMSO  Data  and 
Repositories  Technology  Working  Group  (DRTWG)  co-chaired  by  Dr.  Chien  Huo,  acting  M&S 
Functional  Data  Administrator,  and  Teresa  Lunt,  the  Program  Manager  for  Information  Security 
at  ARPA/CSTO.  The  objective  was  to  familiarize  people  working  in  information  security  with 
the  data  security  needs  of  the  DRTWG  community  in  order  to  address  those  needs  in  a  new 
ARPA  information  security  program  that  Lunt  will  be  forming. 
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13.4  MEETING  NOTES 

Dr.  Chien  Huo:  Presented  DoD  M&S  Needs  for  Data  Standardization 

He  reviewed  the  DoD  M&S  management  structure,  the  data  challenges,  ongoing  activities  of  the 
Data  and  Repositories  Technology  Working  Group  (DRTWG),  action  plans,  the  M&S  data 
administration  road  map  and  the  status  of  the  M&S  Master  Plan  and  the  place  of  data  and  data 
issues  within  it.  In  particular,  the  DRTWG  has  identified  community  needs  to  include:  a 
distributed  M&S  Resource  Repository  (MSRR)  system,  data  standards  for  complex  data,  data 
verification,  validation  and  certification,  identification  of  authoritative  data  sources,  and 
determining  data  security  requirements.  Huo  also  distributed  a  memorandum  signed  by  CAPT 
James  Hollenbach,  Director  of  DMSO,  defining  the  Terms  of  Reference  for  the  DMSO  M&S 
Data  Security  Task  Force.  This  provides  a  charter  for  how  the  TF  shall  operate.  He  asked  for 
comments  on  the  charter  be  returned  to  him  no  later  than  January  14, 1995. 

Ms.  Teresa  Lunt:  Meeting  Objectives 

Lunt  discussed  the  meeting  with  respect  to  the  new  ARPA  security  program  she  will  be  starting 
up.  She  invited  security  people  to  the  meeting  to  listen  to  the  M&S  data  security  problems  and 
noted  that  they  were  attending  on  their  own  since  there  is  no  current  ARPA  program.  Most  of 
the  security  people  work  in  research,  some  on  developing  products. 

Terry  Mayfield  identified  himself  as  an  IDA  employee  working  in  the  security  area  that  had  been 
asked  by  DMSO  to  attend  the  meeting  and  could  be  a  contact  point  in  addressing  some  of  the 
issues. 

Ms  Iris  Kameny:  Briefed  on  M&S  Security  Issues 

DMSO  had  sent  out  a  white  paper  covering  these  issues  prior  to  the  meeting.  An  issue  not 
explicitly  covered  in  the  white  paper  was  the  fact  that  the  solution  of  most  of  the  issues  will 
require  policy  development/changes  as  well  as  technology.  It  was  noted  that  the  current  world  is 
very  different  from  the  cold  war  world  during  which  much  of  the  current  security  policy  was 
developed.  Currently,  DoD  needs  to  be  able  to  quickly  put  together  Joint  Task  Forces  for 
deployment  to  many  parts  of  the  world,  with  little  notice,  and  to  address  many  situations  other 
than  war.  Modeling  and  Simulation  plays  an  important  role  in  these  new  operational  missions 
since  it  can  be  used  to  train,  to  rehearse,  to  address  what-ifs,  etc.  This  requires  interoperability  of 
forces  and  M&S  representing  those  forces  that  requires  sharing  of  data  across  organizations  that 
have  always  held  their  data  close  and  protected  it.  We  need  to  face  the  issue  of  interoperability 
(requiring  data  sharing)  versus  the  need  to  protect  data.  Consistent  policies  are  needed  across 
DoD  (and  probably  the  federal  government)  to  protect,  release,  and  downgrade  data.  Attention 
also  needs  to  be  paid  as  to  whether  different  policies  should  apply  in  peacetime  and  in  crisis  and 
if  so,  what  implication  does  this  have  for  the  DoD  desire  "to  train  as  we  fight"  and  "fight  as  we 
train.” 

(With  respect  to  policy  issues,  it  was  said  that  William  Moss  supports  Mr.  Davidson  (DIA)  and 
that  Marty  Pickens  is  in  the  DISA/CISS  policy  office.) 

Nine  M&S  security  issues  were  discussed.  The  first  seven  dealt  with  data  security  and  the  last 
two  with  Distributed  Interactive  Simulation  (DIS)  security  needs.  The  nine  issues  are: 

1.  Data  exchange 

2.  Data  access 

3.  Data  aggregation 

4.  Classification  of  enumerated  values 

5.  Protection  of  data  source  in  downgrading  data 

6.  Releasability  of  data/information 

7.  Standardized  security  labels 
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8.  Multilevel  secure  DIS  exercises 

9.  DIS  component  participating  in  exercises  at  different  security  levels 

A  question  was  asked  about  how  the  recent  Synthetic  Theater  of  War  -  Europe  (STOW-E) 
exercise  that  utilized  DIS  was  accredited  since  its  components  operated  at  different  security 
levels. 

Mr.  Howard  Haeker:  Director  of  the  TRAC  Automated  Data  Center  (TADS)  discussed  issues 
with  respect  to  furnishing  unclassified  data 

TADS  currently  contains  only  classified  data,  yet  Haeker  receives  requests  for  him  to  change 
classified  data  to  unclassified  data  for  some  exercises.  The  issues  include: 

—  How  to  convert  classified  data  to  unclassified  data 

—  Releasability  to  foreign  countries  (i.e.,  he  may  be  allowed  to  release  a  model  or  simulation 
but  not  the  data  that  the  foreign  country  needs  to  run  the  software) 

—  Acquiring,  gathering  and  maintaining  classification  labels  of  data  sometimes  at  the  data 
element  level:  this  will  require  extensive  metadata  but  right  now  isn't  done. 

Organizations  currently  put  a  broad  caveat  on  their  data  saying  it  is  all  secret,  or  all  no 
foreign  or  all  no  contractor,  etc.  requiring  time  consuming  activity  to  get  exceptions. 

—  Releasability  of  unclassified  data  is  a  problem  because  it  falls  under  technology  transfer 
policy/regulations  preventing  it  from  being  released  to  foreign  nations. 

—  The  releasability  problem  can  also  be  extended  to  the  protection  of  information  for 
proprietary  reasons. 

LtCoI  DAN  HOGG:  Briefing  on  Data  Security  Issues  From  the  J8/OASIS  Point  of  View 

The  Joint  Staff  need  was  to  share  Secret  data  across  the  CENTCOM  Conventional  Forces 
Database  (CFDB)  and  J8's  Operational  Analysis  and  Simulation  Interface  System  (OASIS). 
CFDB  is  at  the  Secret  system  high  level  and  OASIS  is  at  the  Top  Secret  system  high  level 
though  the  majority  of  its  data  is  individually  classified  at  the  secret  level.  The  objective  was  to 
migrate  the  OASIS  Top  Secret  high  configuration  to  one  supporting  multilevel  operations.  The 
migration  (1)  would  segregate  data  available  to  users  with  S  and  TS  clearance  levels  using 
mandatory  access  controls,  (2)  support  client/server  Ingres  applications  using  Sun  workstations 
accessing  Sequent  data  servers,  (3)  support  existing  single  level  applications,  and  (4)  support 
eventual  access  by  Secret  users  via  a  secure  WAN  to  the  CFDB.  The  approach  was  to  upgrade 
the  Sequent  servers  to  Secure  PTX  version  2.1.  One  copy  of  Ingres  and  Ingres/Net  with  two 
DBMS  server  processes  runs  under  Secure  PTX,  one  server  runs  at  Secret  and  the  other  at  Top 
Secret.  The  Ingres  installation  at  TS  contains  the  full  OASIS  database  (Top  Secret  data  and  a 
redundant  copy  of  the  Secret  data).  The  Ingres  installation  at  Secret  contains  only  Secret  data. 
The  Ingres  Replicator  synchronizes  the  replicated  copy  of  Secret  data  in  the  Top  Secret  server 
with  the  data  in  the  Secret  server  serving  as  a  one-way  write-up  trusted  process.  Another  way  to 
have  done  this  was  to  use  a  firewall  to  physically  separate  the  two  servers  and  to  have  hooked 
them  up  only  when  needed  for  writing-up. 

An  identified  issue  is  that  the  data  has  to  be  tagged  for  security  and  for  audit  trail,  which  will 
increase  the  database  size  a  little  or  a  lot  depending  on  the  granularity  size  of  the  data  being 
tagged  (e.g.,  table,  row,  or  individual  data  value  level).  How  do  you  address  this  trade  off? 

Another  issue  is  that  of  filters.  DIA  wants  to  put  out  a  generic  data  product  on  21  tapes  and  let 
users  filter  out  what  they  need  but  OASIS  would  like  the  filtering  to  be  done  by  the  producer  and 
not  the  user.  They  would  like  to  be  able  to  request  only  the  data  they  want.  DIA  has  a  MIDS 
tool  to  filter  data  but  it  operates  only  at  the  SCI  level.  Question  is  where  should  filters  reside? 

Another  issue  has  to  do  with  labeling  and  releasing  data.  They  need  a  document  to  tell  them  how 
to  label  data,  handle  it  at  different  levels,  etc. 
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Lastly,  where  do  they  go  for  information  about  how  to  release  data  to  foreign  countries?  They 
also  have  a  problem  in  that  the  M&S  may  be  releasable  but  do  foreign  analysts  no  good  without 
the  accompanying  data. 

Mr.  Mark  Hopkins:  CENTCOM  Issues 

MOP  60  and  a  recent  CJCSI  on  joint  policy  boils  down  to  a  need-to-know.  There  needs  to  be  a 
way  to  determine  who  has  a  need-to-know  so  data  can  be  made  available  to  them.  MOP  60  is 
very  general/generic  and  mainly  deals  with  handling  WWMCCS  data  and  is  mainly  used  as  a 
reason  for  denying  service. 

OPSEC/aggregation:  refers  to  fact  that  force  data  is  mainly  unclassified  but  the  aggregation  of  it 
forces  an  upgrade  to  secret  classification. 

There  is  also  concern  about  how  to  handle  or  get  exceptions  to  the  no  foreign  and  no  contract 
caveats. 

Title  10  tries  to  enforce  separation  of  service  data  from  DoD  data,  i.e.,  makes  service  data 
unavailable  to  DoD.  This  has  a  great  affect  on  sharing  data  for  M&S. 

Steve  Galloway  (for  Major  Steve  Zeswitz  (USMC)):  Discussing  the  Needs  of  the  Marine 
Corps  M&S  Office 

There  are  no  data  security  issues  the  Marine  Corps  has  that  have  not  been  discussed  here  already. 
They  have  had  to  run  their  information  systems  at  system  high  to  prevent  dealing  with  multilevel 
security.  The  current  problem  is  that  no  one  wants  to  do  M&S  classified,  people  want  others  to 
give  them  sensitive  data  and  just  let  them  use  it  in  an  unclassied  game/M&S.  If  you  don't  know 
the  source  of  the  data  and  how  it  was  produced  (e.g.,  downgraded)  then  questions  will  be  asked 
because  the  outcome  of  simulations  will  be  strange.  The  war  colleges,  agencies,  etc.  are 
beginning  to  operate  at  Secret  across  Services  as  the  safest  bet.  If  you  look  through  Security 
documents  you  will  find  standards  for  markings  etc.  but  they  have  been  designed  for  people 
working  on  manual  systems  as  well  as  automated  ones. 

If  we  are  to  use  filters  for  downgrading  data,  then  we  need  standards  in  the  form  of  central 
baseline  operating  procedures  to  ensure  correct  use.  He  mentioned  lessons  learned  from 
TRADOC  and  DIA  as  data  is  migrated.  The  no  contractor  caveat  is  a  problem  because  if  a 
contractor  is  implementing  a  simulation  or  doing  analysis  he  not  only  needs  the  data  but  he  may 
need  to  know  what  its  source  was  and  how  it  was  derived. 

There  is  a  data  aggregation  problem. 

With  respect  to  data  release,  the  Freedom  of  Inf ormation  Act  (FOIA)  has  resulted  in  the  press, 
authors,  etc.  making  requests  for  data/information  that  the  Services  would  normally  protect  or  at 
least  hold  close  because  of  lack  of  need-to-know  but  FOIA  ends  up  turning  this  around  and 
forcing  them  to  defend  not  releasing  the  data. 

Ms.  Lana  McGIynn:  Army  Modeling  and  Simulation  Management  Office 

Suggested  that  the  starting  point  in  all  of  this  is  to  find  out  what  policy  currently  exists,  and  since 
it  isn't  all  broken  (i.e.,  bad)  find  out  what  is  broken  and  address  those  problems. 

The  Army  has  regulations  (e.g.,  A-380-5  on  Information  Systems  Procedures  and  AR5-1 1  on 
M&S  and  associated  data)  that  address  many  of  these  issues.  Mr.  Hollis  has  release  authority  for 
all  M&S  and  M&S  data  in  the  Army.  There  should  be  similar  policy  available  in  the  other 
Services  and  at  the  OSD  level.  Why  don't  we  start  there? 

With  respect  to  protecting  data  from  release  to  contractors,  what  are  the  policy  restrictions  that 
need  to  be  enforced  upon  contractors  to  whom  data  is  released  by  exception? 
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We  also  need  to  look  at  releasability  policy  in  moving  from  data  to  information  and  to 
intellectual  property  rights. 

LCDR  Don  Hagerling  (N643)  (for  LCDR  Bruce  Stewart):  MLS  Requirements  for  C3I 
Database  Managers:  The  Challenge  to  Protect  Navy  Information  Resources 

The  Navy  is  leveraging  the  use  of  people  through  the  use  of  distributed  systems.  The  best  ADP 
practice  is  to  transfer  functions  from  people  to  information  systems.  Navy  Information  Systems 
will  have  to  be  MLS  and  there  needs  to  be  automated  transfer  of  information  at  the  proper  level. 
The  risk/vulnerability  is  increasing  as  more  people  gain  access  through  connectivity  and  more 
machines  are  interconnected.  This  briefing  was  put  together  to  educate  the  operational 
commander. 

MLS  databases  are  important  because  the  heart  of  any  C3I  system  is  the  Database  Manager 
(DBM),  that  is  where  we  are  trying  to  automate  the  complex  human  function,  and  most  DBMs 
are  immature.  He  went  over  the  definition  of  a  trusted  system,  and  assurance  (an  art  not  a 
science),  and  discussed  certification  and  accreditation. 

He  discussed  the  TAMPS  security  requirements:  used  to  plan  missions  of  varying  sensitivities; 
used  by  users  with  different  clearances  and  need-to-know;  data  storage  units  (DSU)  are  reused; 
will  contain  software  and  data  that  is  classified,  database  updates  are  received  from  different 
systems  at  different  security  levels  (U  to  S);  databases  will  contain  information  at  varying 
information  classification  levels;  classified  data  and  unclassified  or  confidential  maintenance 
data  may  be  written  to  the  DSU  during  a  mission.  He  went  over  security  architecture  options 
(MLS  LAN,  MLS  database  servers,  MLS  workstations,  MLS  front  ends).  He  reviewed  the  Navy 
development  of  MLS  functions  for  OSS  and  discussed  the  phase  5  of  insertion  of  trusted 
technology  in  OSS,  which  is  when  security  properties  are  hilly  integrated  and  supported  by 
certification  evidence. 

They  would  like  to  automatically  release  and  downgrade  data  but  need  enforceable  rules  for 
addressing  data  aggregation  and  data  inferencing. 

He  believes  they  need  mandatory  access  control  (MAC)  at  the  data  element  level  requiring 
element  level  labeling  because  row  level  labeling  is  too  large  a  granularity. 

He  mentioned  three  needs,  for:  (1)  handling  time/event  sensitivity,  (2)  trusted  object  oriented 
RDBM,  and  (3)  trusted  synchronization  methodology  that  can  separate  class  and  accuracy. 
Synchronization  is  a  Navy  problem  because  of  limited  bandwidth.  Synchronization  between 
levels  of  classification:  higher  classification  does  not  necessarily  mean  higher  accuracy  (need  to 
deal  with  poly  instantiated  data). 

The  Navy  does  have  rules  for  aggregation:  data  describing  1%  of  the  force  capability  is  labeled 
unclassified,  10%  confidential,  and  50%  Secret. 

The  Navy  needs  protection  against  inferring  the  location  of  ships  and  about  inferring  bomb 
damage.  They  are  addressing  this  by  looking  at  a  MAC  query  manager  that  will  classify 
predetermined  C2  queries  (while  all  ad  hoc  queries  will  run  at  high  level  mark). 

The  DBM  is  critical,  must  be  distributed  and  MLS,  but  is  too  immature  to  be  part  of  a  current 
MLS  system. 

They  are  working  with  DISA  on  data  labeling,  and  mentioned  George  Mitchell  at  NS  A  and  Tom 
Bartee  at  IDA  who  is  the  Navy  representative  to  the  National  Committee  for  Information 
Security. 
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Dave  Gunning  (ARP A):  Intelligence  Integration  of  Information  (13) 

The  DRTWG  has  been  following  Gio  Wiederhold's  program  in  the  development  of  many  of 
these  ideas  over  the  past  several  years  since  Gio  is  a  member  of  the  group.  Gunning  gave  us  a 
very  well  prepared  briefing  which  focused  on  the  critical  issues  and  techniques. 

The  technical  issues  are:  summarizing  information,  resolving  heterogeneity,  living  with  legacy 
systems,  and  establishing  infrastructure  in  the  form  of  interchange  protocols  and  modular 
architecture. 

The  approach  to  information  integration  is  composed  of  three  parts:  use  of  domain-specific 
mediators  (utilizing  domain  knowledge  to  integrate  data),  use  of  information  interchange 
protocols  (example  of  KQML  providing  a  protocol  for  agent  communication)  and  use  of 
wrappers  and  standard  interfaces. 

There  are  a  number  of  current  13  research  applications  and  testbeds,  including  a  ACPT  Target 
Query  Mediator  which  is  a  model-based  mediator;  Genie:  broker  of  satellite  data;  CoBase 
which  deals  with  approximate  queries;  and  the  National  Industrial  Information  Infrastructure 
Protocols  (NIIIP)  which  is  developing  a  NIUP  architecture. 

Currently,  the  mediators  are  hand-built  and  seem  to  work  well  for  relational  and  object-oriented 
DBMSs  but  in  the  future  we  need  automated  tools  to  help  in  their  construction. 

Future  directions  include:  expansion  to  cover  unstructured  data;  improved  development  tools 
(e.g.,  reference  architecture  for  information  integration,  mediation  and  wrapper  toolkits  and 
automatic  generation  techniques);  and  enhanced  application  demonstrations. 

Teresa  Lunt  said  that  she  has  done  work  on  describing  security  policy  for  heterogeneous  sources. 
One  could  see  a  possibility  for  each  M&S  data  center  to  have  a  mediator  that  knew  about  its  data 
and  security  policy  and  a  mediator  of  mediators  to  enforce  security  policy  between  data  centers 
via  their  respective  mediators. 

The  13  effort  could  be  applied  to  the  M&S  Resource  Repository  system  need  for  common  tools 
for  resource  exchange  and  should  be  looked  at  more  closely  by  the  DRTWG  Repository 
Subgroup. 

TomHaigh:  Database  Security  Technology 

Tom  works  for  Secure  Computing  Corporation  which  was  originally  a  part  of  Honeywell  and  has 
develop  the  Lock  DBMS  (based  on  trusted  Oracle)  and  an  authentication/identification  product 
called  LOCKOUT. 

Database  security  research  directions  are  toward:  tools  for  defining  MLS  DBs  with  inference 
protection;  tools  for  installing  MLS  DBs;  understanding  what  real  users  need  (e.g.,  data  model 
issues  of  granularity  of  labeling  and  integrity  across  levels,  and  query  language);  support  for 
trusted  transactions;  architecting  for  assurance;  and  addressing  the  interplay  or  trade  off  between 
secure  DBMS  and  distributed  DBMS  concepts. 

Tom  went  over  some  architecture  issues  such  as  the  handling  of  replicated  and  or  fragmented 
data  in  a  MLS  and  assurance  issues  such  as  security  policy,  the  design  and  placement  of  security 
mechanisms  and  the  implementation  of  mechanisms.  He  discussed  labeling  at  different- 
granularity  levels  and  the  different  problems  at  the  different  levels  and  the  differences  in 
approaches.  For  example,  when  labeling  at  the  data  attribute  level,  examples  were  given  of 
including  attribute  labels  in  the  extended  key  (SeaView)  or  including  a  "maintenance  level"  in 
the  extended  key  (LDV  approach  used  by  TRANSCOM  GDSS). 
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He  discussed  the  trusted  subject,  where  the  DBMS  sitting  on  top  of  a  secure  operating  system, 
enforces  MAC  and  DAC  (examples  are  Informix,  Oracle,  and  Sybase)  using  row  level  labels 
with  common  disk  for  storage  of  data  at  all  levels. 


He  showed  a  physically  distributed  architecture  where  the  user  workstations  were  at  different 
security  levels  (could  be  on  LAN)  interfacing  to  a  server  which  has  a  common  operating  system 
which  interfaces  (again  could  be  over  a  LAN)  to  DBMSs  at  each  security  level,  each  running  on 

top  of  a  operating  system  that  interfaces  to  a  disk,  with  a  separate  configuration  of 

DBMS/OS/DISK  for  each  security  level  and  data  replication  of  lower  level  data  in  the  higher 
level.  This  type  of  architecture  is  found  in  SD-DBMS  (Unisys)  and  SINTRA  (NRL). 


He  showed  a  partitioned  approach  where  each  secure  DBMS  is  at  a  single  level  connected  to  a 
workstation  at  the  same  level  (could  be  over  a  LAN)  with  the  DBMSs  connecting  to  a  data  server 
consisting  of  an  operating  system  and  a  single  disk  containing  data  at  all  security  levels_  This  is 
the  approach  used  by  Sea  View,  LOCK  Data  Views,  Oracle-OS  MAC  mode,  LOCK  DBMS. 


Assurance  requires  a  threat  model  specific  to  the  operating  environment,  .  .  , 

policy  that  addresses  all  identified  threats,  analysis  of  the  totality  of  mechanisms  as  designed  to 
enforce  the  policy,  and  testing  to  be  sure  each  mechanism  is  implemented  correctly. 


Ms.  Teresa  Lunt  for  Dr.  Xiaolei  Qian:  Data  Inference  J  , 

Inference  occurs  when  a  low  user  can  infer  high  information  for  the  low  data  he  is  allowed  to 
see.  An  inference  channel  is  a  chain  of  relationships  that  allow  high  information  to  be  interred 
from  low  data.  Inference  problems  can  result  from  incorrect  labeling  or  inconsistent  labeling. 

The  general  problem  is  unsolvable  since  its  solution  would  require  representing  everything  a  user 
can  be  expected  to  know  and  would  require  an  unlimited  amount  of  reasoning  about  the  sensitive 
implications  of  that  knowledge. 

DISSECT  is  a  system  of  detecting  and  eliminating  inference  channels  by  performing  schema- 
level  analysis  rather  than  data-level  analysis  and  can  be  performed  during  database  design  or 
redesign.  It  uses  foreign  key  relations  and  relationships  involved  in  indirect  inference  (e.g.,  type 
overlap  relationships  and  near  key  relationships). 

Compositional  channels  are  detected  through  realization  that  the  database  represents  a  set  of 
foreign  key  relationships  at  different  security  levels  that  can  be  composed  to  form  new 
relationships  or  paths.  The  security  level  of  a  composed  relationship  or  path  is  the  least  upper 
bound  of  the  security  levels  of  the  links  in  the  path.  It  two  paths  of  different  security  levels 
connect  the  same  end  nodes,  then  there  may  be  a  compositional  inference  problem. 

Near-key  relationships  allow  "almost  exact"  inferences  about  dependent  attributes  and  may 
contribute  to  inference  problems  caused  by  a  user's  ad  hoc  queries  that  the  data  designer  mig  t 
not  have  considered.  When  two  attributes  share  the  same  type  and  overlap  in  allowed  security 
levels,  they  are  joinable  and  may  contribute  to  inference  problems  also  caused  by  users  ad  hoc 
queries  that  the  data  designer  might  not  have  considered. 

There  is  a  potential  inference  problem  if:  there  is  a  pair  of  different-sensitivity  paths  between  the 
same  two  entities,  the  high  path  consists  of  a  sequence  of  foreign  key  links,  the  low  path  consists 
of  both  foreign  key,  type  overlap,  and  near-key  links. 

Repair  detected  problems:  by  upgrading  the  security  level  of  some  of  the  relationships.  Several 
low-cost  solutions  may  be  presented  in  the  analysis  and  the  users  may  choose  all  or  part  of  a 
presented  solution  (e.g.,  for  a  partial  solution,  it  is  possible  to  identify  specific  tables  for  data- 
level  monitoring). 
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An  example  of  a  50-table  database  taken  from  a  USAF  air-mission  planning  database  had  14 
potential  inference  channels  which  were  displayed  in  eight  concise  diagrams. 

Future  work  is  to  evaluate  the  severity  of  the  detected  channels  and  to  adapt  DISSECT  use  with 
row-labeled  databases. 

A  prototype  DISSECT  tool  is  available. 

Ms.  Catherine  Meadows:  Data  Aggregation 

Aggregation  arises  when  a  collection  of  data  is  classified  at  a  higher  level  than  its  components. 
Three  types  of  solutions  have  been  proposed: 

1.  Store  collection  at  higher  level  and  selectively  downgrade  keeping  a  record  of  past 
requests  so  nobody  is  given  more  data  than  they  are  authorized  to  see.  Drawbacks: 
covert  channels  in  downgrading  process,  and  pooling  of  data. 

2.  Store  collection  at  lower  level  and  release  selectively  to  those  who  request  data  keeping  a 
record  of  past  requests  so  nobody  is  given  more  data  than  they  are  authorized  to  see. 
Drawbacks:  data  aggregate  not  given  full  protection  by  MLS  system,  and  pooling  of 
data. 

3.  Similar  to  second  solution  but  provide  intermediate  security  labels  to  components  with 
the  intermediate  levels  dominating  the  lower  level  but  being  dominated  by  the  higher 
level.  Also  include  rules  to  compute  labels  on  aggregates  from  labels  on  components  and 
keep  requests  so  that  nobody  is  given  more  data  that  they  are  authorized  to  see. 
Drawbacks:  may  not  be  practical  for  large  aggregates  of  low  granularity  data,  using 
intermediate  labels  may  require  modification  to  the  system,  and  pooling  of  data. 

Discussed  situation  about  five  years  ago  when  different  versions  of  the  solutions  existed  but  it 
was  difficult  to  know  when  to  apply  which  one.  Evaluation  of  use  of  solutions  was  difficult 
because  of  lack  of  examples.  We  need  a  more  informative  characterization  of  the  aggregation 
problem  or  enough  examples  of  different  types  of  problems  that  such  a  characterization  can  be 
constructed.  A  strategy  is  to  develop  a  set  of  questions  about  different  aspects  of  aggregation 
problems,  construct  profiles  of  aggregation  problems  by  applying  the  questions  to  each  one  and 
study  the  profiles  to  develop  a  characterization/taxonomy  of  the  aggregation  problems. 

She  presented  some  questions  to  ask  about  aggregation  problems: 

1.  What  is  really  being  protected? 

2.  What  assumptions  are  we  making  about  collusion? 

3.  Does  the  information  being  protected  change  over  time? 

4.  Who  is  likely  to  access  what?  Can  we  predict  it? 

5.  Dependency  among  aggregate  components. 

6.  Who  is  requesting  the  accesses? 

7.  Does  data  originate  at  the  low  or  high  level? 

Seven  more  questions  about  the  relevance  of  questions: 

1.  Is  it  an  aggregation  problem  at  all? 

2.  How  much  data  do  we  give  a  low-level  individual  permission  to  see? 

3.  Relevant  to  time  intervals  used  in  permissions. 

4.  If  we  can  predict  who  will  make  the  accesses,  we  may  not  have  to  model  it  as  an 
aggregation  problem. 

5.  If  Y  is  dependent  upon  X  so  that  information  about  Y  reveals  information  about  X,  then 
access  to  Y  implies  access  to  X. 

6.  Degree  to  which  the  requester  is  trusted  may  affect  risk  involved. 

7.  Relevant  to  how  much  protection  we  can  expect  to  give  data. 

Meadows  went  through  six  examples  and  suggested  some  further  questions  such 
as: 
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•  What  profiles  do  aggregation  problems  fit?  Are  there  particular  profiles  that  are  more 
preponderant  than  others? 

•  How  complete/useful  is  the  list  of  questions?  How  can  they  be  modified/added  to? 

•  What  are  good  examples  of  aggregation  problems  that  can  be  used  to  construct  profiles? 

Iris  Kameny:  ... 

1 .  I  have  reproduced  Meadow's  briefing  almost  verbatim  because  aggregation  is  a  critical 
issue  for  the  M&S  community  since  we  are  in  the  process  of  compiling  warehouses  of 
data.  The  other  side  to  releasing  the  data  in  a  protected  way  is  how  to  realize  when  ad 
hoc  or  new  data  collections  need  to  be  protected  at  a  higher  classification  level. 

2.  I  will  be  the  point  of  contact  in  the  M&S  community  for  collecting  examples  of  suspected 
aggregation  problems.  Also  send  me  examples  of  new  data  warehouses  and  how  the 
aggregate  label  is  being  determined.  This  should  also  be  a  DIS  issue  when  large  amounts 
of  data  are  aggregated  even  temporarily  for  an  exercise.  I  would  appreciate  it,  if  when 
you  send  me  examples,  you  could  take  the  time  to  try  to  answer  the  questions  Meadow's 
has  suggested. 

LouAnna  Notargiacomo:  Data  Integrity 

There  are  four  relational  model  integrity  rules: 

•  Entity  integrity  -  no  component  of  a  key  is  null 

•  Key  uniqueness  -  each  entity  must  have  a  unique  identifier 

•  Domain  integrity  -  values  for  an  attribute  are  constrained  to  be  within  the  defined  domain 

•  Referential  integrity  -  relationships  maintained  between  primary  and  foreign  keys 

There  is  a  conflict  between  integrity  and  multilevel  security  with  relation  to  key  uniqueness, 
domain  integrity  and  referential  integrity.  In  MLS  environments  objects  may  be  labeled  at 
different  security  levels  and  higher-level  actions  should  have  no  impact  on  lower-level  objects. 
(Some  of  these  problems  were  discussed  previously  by  Tom  Haigh.)  Trusted  DBMSs  provide 
options  to  allow  application  developers  choice  of  security  vs  integrity. 

A  key  uniqueness  and  polyinstantiation  problem  occurs  when  the  key  does  not  include  the 
object's  security  level.  MLS  DBMS  products  that  allow  for  either  choice  are  Oracle  and 
Informix,  Sybase  supports  trusted  stored  procedures  to  allow  the  application  to  make  the  choice. 

Domain  integrity  is  handled  by  labeling  integrity  constraints  at  the  level  at  which  they  are 
created.  Enumeration  of  higher  level  values  or  sensitive  constraints  must  be  labeled  high  and 
higher  level  constraints  cannot  be  used  to  control  lower  level  operations  due  to  the  inference 
problem. 

Referential  integrity  constraints  can  be  defined  to  control  relationships  between  objects  at 
different  levels  and  rules  can  be  defined  to  either  cascade  or  disallow  updates  or  deletes  in  order 
to  maintain  the  correct  state.  Some  MLS  DBMSs  prohibit  the  modification  of  a  low  object  due 
to  a  high  operation  to  prevent  an  illegal  channel. 

MLS  DBMSs  provide  options  for  use  of  trusted  trigger  and  stored  procedures  to  enforce  more 
complex  application-specific  integrity  rules  that  have  cross-level  dependencies.  Sybase  Secure 
SQL  Server  provides  the  ability  to  define  a  security  level  execution  range  for  a  trigger  or  stored 
procedure. 

Concurrency  control  locking  procedures  can  generate  illegal  channels.  Solutions  are 
multiversion  time-stamp  ordering  and  soft  locking.  (Sybase  ignores  the  problem,  Oracle  uses 
multilevel  locking,  and  Informix  soft  locking.) 

The  Clark  Wilson  integrity  model  addresses  business  rules  and  labels  objects  with  an  integrity 
designation  such  that  constrained  data  objects  (CDIs)  are  integrity-protected  and  can  only  be 
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modified  through  certified  transformation  procedures  and  unconstrained  data  items  (UDI)  are 
unprotected.  Transformation  procedures  can  transform  CDIs  from  valid  to  valid  state  or  UDIs  to 

GDIs.  Enforcement  of  integrity  is  through  user,  transformation  procedures,  and  use  of 

constrained  data  objects;  authentication  of  user;  and  audit  of  transformation  procedure  events. 

MITRE  has  developed  a  model  for  Clark-Wilson  integrity  within  a  trusted  environment 

and  found  that  the  C-W  integrity  policy  enforcement  could  be  added  to  MLS  DBMS  without 
interfering  with  multilevel  operation.  The  Sybase  Secure  SQL  Server  supports  Clark-Wilson  an 
Informix  is  exploring  the  development  of  such  a  capability. 

(Note  from  Iris:  We  should  look  at  this  as  a  formal  basis  for  enforcing  data  quality  within  data 
centers.) 

In  summary,  a  fundamental  tradeoff  exists  between  integrity  and  security.  MLS  DBMS  products 
allow  application  developers  to  configure  security  vs  integrity  enforcement. 

Discussion: 

John  Griffiths:  Announced  that  the  Intelligence  Community  M&S  Directory  will  be  m  two  parts: 
unclassified  and  classified.  The  unclassified  part  will  reside  at  DMSO.  They  have  developed  a 
security  model  on  how  they  will  manage  both  directories  on  the  same  machine  within  the  1C. 

Discussion  of  world  wide  web  support  for  classified  M&S  data  center  home  pages.  People 
would  like  to  find  out  how  the  IC  did  INTELINK  and  government  employees  are  pemutted  to 
attend  demonstrations  and  perhaps  glean  lessons  learned  and  some  insight  into  handling  the 
secure  data  center  issue.  Janet  Morrow  will  furnish  a  POC. 

Mike  Hopkins:  J6  had  a  contractor  do  a  study  on  MLS  with  respect  to  use  of  a  TS  LAN  and  a  S 
LAN.  Contact  him  for  information. 

An  NSA  program  office  that  was  previously  part  of  the  NCSC  supports  research  into  database 
security,  information  system  security,  intrusion  detection,  operating  syst< sm i  security, met  work : 
security  etc  There  is  a  problem  in  identifying  real  customer  needs.  Most  funding  is  being  spent 
on^long  range  issues.  The  point  of  contact  is  Nick  Piazolla.  The  MISSI  (Multilevel  Inflation 
System  Security  Initiative)  program  is  developing  commercial  products  that  will  be  available  to 
DoD.  Don  Marks  said  there  are  a  whole  set  of  security  products  available  and  that  we  could  get 
a  briefing  on  them  at  the  next  meeting. 

Discussion  about  M&S  community  needing  access  to  classified  data  and  information  and  CALS 
needing  access  to  classified  images  of  vehicles. 

We  discussed  the  enumeration  document  and  the  need  for  wide  distribution  of  the  classified 
version:  Can  we  do  something  about  this? 

Ron  Hofer  -  policy:  Suggested  that  we  group  issues  into  technology  issues  and  policy  issues,  the 
latter  of  which  the  group  cannot  address.  Iris’  view  is  that  the  two  areas  overlap  and  we  can  take 
the  need  for  policy  changes  up  to  the  DMSO  Director  and  the  EXCIMS  where  they  could  be  sent 
up  the  chain  at  DoD.  Jim  Augins  suggested  that  we  be  briefed  on  existing  security  policy  and 
procedures  of  various  DoD  Components. 

Discussion  led  by  Howard  Haeker:  What  to  do  about  request  for  de-classified  data. 

There  is  a  need  for  filters  and  sanitization  guidance.  Can  we  come  up  with  sanitization  methods . 
If,  through  data  de-classification,  the  environment  for  operational  use  and  M&S  use  becomes 
fuzzy,  then  there  are  problems  for  training  and  other  uses  of  M&S.  It  may  be  a  ques  ion  o 
making  an  entire  environment  protected.  An  issue  is  whether  we  can  do  adequate  mission 
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rehearsals  with  unclassified  data.  Another  issue  is  that  most  classified  data  is  denied  to 
contractors  but  contractors  need  the  data  and  information  about  the  data  in  order  to  build 
classified  M&S  that  can  be  verified,  validated  and  accredited  (VVC). 

Mike  Williams:  Suggested  that  there  is  a  standard  way  of  labeling  classified  data  and  will  report 
back  on  this. 

Connie  Davis:  We  need  to  define  the  scope  of  the  issues  this  group  will  address  with  respect  to 
information  security  and  the  role  of  data  administration  in  information  security.  She  said  that 
every  automated  system  has  a  published  guide  at  DTIC  that  tells  exactly  why  its  data  is 
classified,  its  sources,  etc.  She  also  has  DISA  issue  papers  dealing  with  data  security  and  data 
administration.  She  gave  Chien  Huo  a  copy  of  a  document  on  policies  and  procedures  produced 
for  DISA  by  SAIC  and  also  referred  everyone  to  Volume  6  of  the  TAFIM  which  addresses 
security. 

George  Hurlbert:  Gave  short  briefing  on  TECNET's  plans  for  multilevel  security  using  a  MLS 
host.  They  are  working  with  NSA  to  put  together  a  Concurrent  Systems  Security  Engineering 
(CSSE)  process.  The  team  meets  one  week  during  the  month.  They  are  addressing  whether 
procedures  can  be  developed  to  mitigate  shortfalls  in  hardware  and  software.  Their  MLS 
approach  deals  with  flat  files  controlled  at  the  operating  system  level  and  across  interconnecting 
machines.  They  won’t  do  MLS  wrt  data  until  they  can  label  at  the  data  element  level. 
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13.5  WRAPUP 

1.  Next  meeting  will  be  at  IDA  on  Thursday,  February  9  from  8-12 

2.  We  need  a  strawman  document  for  requirements  for  M&S  data  security 

3.  We  need  to  evaluate  and  understand  current  DoD  Component  security  policy  and 

procedures  to  determine  where  they  are  inadequate. 

4  Iris  Kameny  suggests  that  some  of  the  security  people  at  the  meeting  may  want  to  make 
contact  with  the  M&S  people  with  problems  in  view  of  addressing  those  problems  in  the 
ARPA  future  BAA  for  Information  Security  proposals. 
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13.6  ACTION  ITEMS 


micuuccs.  TJ 

1 .  Return  comments  about  the  Data  Security  Requirements  Task  Force  charter  to  Chien  Huo 
by  January  14, 1995 

2.  Return  examples  of  downgrading  data  to  Iris  Kameny 

Howard  Hacker » 

1.  More  on  defining  and  addressing  issues  of  declassifying  data  through  filters,  sanitization 
methods  and  techniques 

Iris  Kameny: 

1 .  POC  to  provide  information  on  data  aggregation  problems 

2.  Address  object  architecture  with  Ron  Hofer  and  Janet  Morrow 

Teresa  Lunt/Chien  Huo: 

1.  Arrange  briefing  from  NS  A  on  current  available  security  products  (re  suggestion  from 
Don  Marks) 

2.  Briefing  suggested  on  physical  security  for  next  meeting 

3.  Arrange  briefing  from  Louis  Anderson,  OSD/CIM  expert  on  releasability 

4.  Lana  McGlynn  will  review  and  present  Army  security  policy.  Identify  people  and  assign 
similar  task  to  other  services  and  relevant  organizations  such  as  DMA. 

5.  Terry  Mayfield  will  brief  on  value  of  TAFIM  especially  Volume  6  at  the  next  meeting 

Lana  McGlynn: 

1.  Review  Army  security  policy  and  present  at  next  meeting 

Janet  Morrow: 

1.  Work  with  Iris  Kameny  on  object  architecture 

2.  Get  POC  to  INTELINK  Standards  Committee  to  Chien  Huo 

LouAnna  Notargiacomo: 

1 .  Send  information  about  index  to  security  documents  to  Chien  Huo 
Eleanor  Schroeder: 

1 .  Report  back  on  lessons  learned  from  the  Navy  Integration  Data  Management  System 

Mike  Williams: 

1 .  Report  back  on  standard  way  of  labeling  data 
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14.1  AGENDA 


THURSDAY,  DECEMBER  15, 1994 


0800  -  0830  Introductions  and  Administrative  Remarks  -  Chien  Huo,  Iris  Kameny,  Mike 
Hopkins 

0830  -  0900  DoD  System  Interfaces  &  Data  Exchange  -  Ms  Mary  Polydys 

0900  - 1000  Finalization  of  Categories/Taxonomy  for  JM&S  Data  Sources  Directory  -  Iris 
Kameny,  Dave  Danko,  Mike  Hopkins 


1000  -  1015  Break 

1015  -  1200  Data  Sources  Responsibilities  -  Mike  Hopkins 


1200  -  1300  Lunch 

1300  -  1400  Status  of  JM&S  Data  Sources  Survey  -  Mike  Hopkins 


1400  -  Adjourn 


14.2  ATTENDEE  LIST 
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14.3  MAIN  OBJECTIVES  OF  MEETING 

The  main  objective  of  this  meeting  was  to  finalize  the  Authoritative  Data  Sources  Directory 
Taxonomy.  Several  action  items  were  assigned  at  the  last  meeting  (3  November  1994  at 
USCENTCOM  in  Tampa,  FL)  and  the  results  of  these  action  items  were  to  be  presented  at  this 
meeting  for  incorporation  into  "version  1.0"  of  the  taxonomy.  Dave  Danko  had  an  action  iteni  to 
draft  a  "Phase  II"  format  for  the  data  sources  survey  and  this  was  to  be  presented  and  discussed  at 
this  meeting.  Lastly,  a  review  of  the  responsibilities  of  data  sources  and  data  customers  as 
defined  by  this  group  was  to  be  finalized  for  submission  to  DMSO’s  MSWG.  It  should  be  noted 
that  the  taxonomy  is  still  not  finalized  -  detailed  notes  to  follow.  Also,  the  agenda  was  really  a 
guideline  and  was  adjusted  as  necessary. 
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VEHICLES,  LAND  VEHICLES,  SEA  VEHICLES,  and  SPACE  VEHICLES.  This 
would,  in  effect,  broaden  these  categories  to  also  include  weapons.  Thus  VEHICLES  and 
WEAPONS  could  be  level  4  categories.  Also  MONITORS  was  removed  and  MISSILES 
was  added  as  a  level  3  category. 

The  ENVIRONMENT  definition  needs  to  be  modified  to  include  oceanography.  See 
proposed  definition  in  Appendix  A.  Discussion  ensued  on  whether  EFFECTS  should  be 
added  as  a  new  level  2  category.  Richard  Siquig  said  that  many  M&S  users  who  need 
environmental  data  do  not  necessarily  know  how  the  environment  actually  affects  their 
simulations.  It  was  unclear  whether  databases  exist  that  contain  environmental  effects. 
Although  Mr.  Siquig's  point  was  well  taken,  it  was  decided  that  there  was  no  feasible  way 
to  make  the  directory  access  using  this  taxonomy  fool-proof.  It  was  generally  believed 
that  subject  matter  experts  would  be  involved  in  the  simulation  development  process  and 
that  this  directory  would  be  of  help  to  those  people  in  finding  the  authoritative  data 
sources  that  they  would  need  to  support  their  simulation.  One  of  the  major  problems  for 
the  M&S  community  today  is  not  so  much  not  knowing  how  to  use  the  data,  but  where  to 
find  the  data.  This  directory  (and  hence  taxonomy)  is  to  solve  this  problem.  Further 
evolutions  of  the  directory  could  possibly  include  EFFECTS  as  a  level  2  category.  It  was 
also  noted  that  nuclear,  biological,  and  chemical  effects  were  not  included  as  well  as 
effects  of  obstacles.  Under  the  level  2  category  of  TERRAIN,  it  was  decided  that 
SURFACE  MATERIALS  be  modified  to  SOILS/SURFACE  MATERIALS  and 
POPULATION  to  POPULATED  PLACES.  Under  WEATHER,  it  was  decided  to 
change  SEASONAL  to  CLIMATOLOGICAL  and  DAILY  to  DIURNAL.  The  EM 
category  was  expanded  to  EM/EO  (electromagnetic/electrooptical)  and  a  proposed 
breakdown  was  provided  to  include  NATURAL  EMITTER  CHARACTERISTICS, 
MANMADE  EMITTER  CHARACTERISTICS,  RECEPTOR  CHARACTERISTICS 
COMMUNICATIONS/INFORMATION  TRANSFER,  and  PROPAGATION  EFFECTS. 
This  breakdown  was  provided  by  Jim  Hammond.  NAVIGATION  sub-breakdown  was  re¬ 
defined  into  OBSTRUCTION,  LANDMARKS,  NON-ELECTRONIC,  INERTIAL, 
RADIO,  SATELLITE,  LIMITS. 

The  TTP  COGNITIVE  definition  has  a  minor  typographical  error  which  will  be  changed. 
See  corrected  definition  in  Appendix  A.  Subcategory  C3I  was  removed. 

Under  FORCE  DESCRIPTION,  the  level  2  categories  of  JOINT  FORCES  and 
COMBINED  FORCES  were  added. 

In  the  definition  for  POLITICAL,  the  word  "geography"  will  be  removed.  What  was 
previously  termed  "geopolitical,"  e.g.,  political  boundaries,  are  found  under  the 
TERRAIN  subcategory  of  ENVIRONMENT. 

No  major  discussion  occurred  concerning  HUMAN  FACTORS. 

The  word  "combat"  will  be  removed  from  the  term  portion  of  the  definition  of  SUPPORT 
SERVICES.  This  will  reflect  the  change  made  at  the  last  meeting  when  COMBAT 
SUPPORT  SERVICES  was  renamed.  See  Appendix  A. 

Cathy  Corley  presented  a  subcategory  breakdown  for  SCENARIO.  The  subcategories 
presented  and  accepted  were  ARMY,  NAVY,  AIR  FORCE,  MARINE  CORPS, 
JOINT/COMBINED,  OPERATIONS  OTHER  THAN  WAR,  and  PIECES  (aka 
PLANNING  GUIDANCE).  These  subcategories  were  determined  to  be  adequate  in 
order  to  define  "scenario"  as  a  description  of  a  conflict,  including  who  is  involved,  the 
equipment  they  have,  locations,  environmental  and  political  constraints,  guides  as  to  how 
they  are  to  fight,  and  the  purpose  of  the  conflict. 
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The  term  portion  of  the  definition  for  TEST  needed  to  include  TEST  RESULTS  to  reflect 
the  "new"  top  level  category  as  determined  at  the  November  meeting.  Also  a 
typographical  error  in  the  definition  itself  was  corrected.  See  Appendix  A.  The  level  2 
categories  were  renamed  to  OPERATIONAL  TESTING  and  DEVELOPMENTAL. 
TESTING. 

The  proposed  and  accepted  level  2  categories  for  UNIT  PERFORMANCE  were 
READINESS  and  HISTORICAL. 

The  MISCELLANEOUS  category  remained,  but  with  no  level  2  categories. 

DATA  STANDARDS  was  removed  as  a  level  2  category  under  MISCELLANEOUS  and 
made  into  a  top  level  category.  It  was  proposed  that  this  be  broken  down  into  directories, 
metadata,  and  others  as  appropriate. 

There  was  discussion  as  to  whether  there  needs  to  be  separate  directories  for 
Authoritative  Data  Sources  and  for  Databases  as  previously  planned  or  whether  the 
Authoritative  Data  Sources  data  model  is  a  subset  of  the  Databases  data  model  and  the 
two  could  be  melded  into  one  directory.  This  will  be  dependent  on  agreement  between 
the  data  models  especially  after  consensus  on  results  from  Dave  Danko's  proposed 
changes  to  the  survey  which  might  introduce  new  data  elements  in  the  Authoritative  Data 
Sources  data  model). 

B.  Data  Sources  Responsibilities 

The  definitions  were  presented  for  AUTHORITATIVE  DATA  SOURCE,  and  DATA 
CENTER.  It  was  noted  that  the  definition  for  DATA  CENTER  is  really  for  an  M&S 
DATA  CENTER.  Responsibilities  for  both  DATA  SOURCES  and  DATA  CUSTOMERS 
were  presented.  Please  see  Appendix  C  for  details.  Comments  and/or  revisions  are  to  be 
provided  to  Chien  Huo  NLT  1 1  January  1995.  These  definitions  and  responsibilities  will 
be  forwarded  (incorporating  any  requested  modifications)  to  the  DMSO  MSWG. 

C.  Status  of  JM&S  Data  Sources  Survey 

No  new  directory  was  distributed  at  the  meeting.  If  changes  are  needed,  please  notify 
Mike  Hopkins.  Unfortunately,  not  much  time  was  left  for  intense  discussion  on  this 
agenda  item.  The  work  that  Dave  Danko  did  was  presented  for  review.  Contact  either 
Mike  Hopkins  or  Dave  Danko  if  you  have  not  received  a  copy  of  his  extension  to  the 
survey  questionnaire  and  would  like  one  for  review.  Mr.  Danko  plans  to  forward  a 
diskette  to  Peter  Valentine  so  that  the  information  will  appear  on  Peter's  WWW  home 
page.  Please  note:  If  you  have  a  copy,  you  have  an  action  item  to  review  his  submission 
and  comment  on  what  you  feel  needs  to  be  included  in  the  Phase  II  survey  questionnaire! 
For  those  people  still  remaining  at  the  meeting,  you  are  listed  under  the  ACTION  ITEMS 
section  for  this. 

D.  Other  Business 

Many  thanks  to  Dave  Danko  and  Cathy  Corley  for  their  excellent  efforts  in  completing 
their  action  items.  Also,  thanks  to  Linda  Calvert  and  Linda  Gonzales  for  filling  in  for  Iris 
Kameny  while  she  was  ill. 

The  NEXT  MEETING  is  tentatively  being  scheduled  for  Thursday,  9  February  1300  to 
1700  at  IDA.  Side  note:  This  is  during  the  week  of  the  next  D&R  plenary  session. 
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14.5  ACTION  ITEMS 

NOTE:  All  action  items  are  due  NO  LATER  THAN  1 1  January  1995  to  CHEEN  HUO  unless 
otherwise  noted. 

A.  Taxonomy 

Jim  Augins: 

( 1 )  Coordinate  SCENARIO  subcategory  definitions  with  Cathy  Corley 
BUI  Bowers: 

( 1 )  Define  JOINT  FORCES  and  COMBINED  FORCES  under  FORCE 
DESCRIPTION. 

(2)  Provide  all  definitions  of  FORCE  DESCRIPTION  subcategory  to  Chien  Huo 
(coordinate  with  Mike  Hopkins  and  John  Griffiths) 

Linda  Calvert:  Fully  define  FINANCE  category 

Cathy  Corleys 

(1)  Provide  definitions  for  subcategories  of  EQUIPMENT  CHARACTERISTICS  and 
EQUIPMENT  PERFORMANCE. 

(2)  Provide  definitions  for  SCENARIO  subcategories.  (Coordinate  with  Jim  Augins) 

(3)  Provide  definitions  for  TEST  RESULTS  subcategories. 

(4)  Provide  subcategory  definitions  for  UNIT  PERFORMANCE. 

Dave  Danko: 

(1)  Provide  definitions  for  TERRAIN  and  its  subcategories. 

(2)  Provide  definitions  for  POLITICAL  subcategories. 

John  Griffiths:  Define  INTELLIGENCE  subcategory  under  FORCE  DESCRIPTION. 
Provide  definition  to  BILL  BOWERS  prior  to  January  1 1,  1995. 

Jim  Hammond:  Provide  definitions  for  EM/EO  and  its  subcategories. 

Mike  Hopkins: 

(1)  Define  ARMY,  NAVY,  MARINE  CORPS,  and  AIR  FORCE  subcategories  under 
FORCE  DESCRIPTION.  Provide  definitions  to  BILL  BOWERS  prior  to  January 
11,1995. 

(2)  Provide  definitions  for  SERVICE  SUPPORT  subcategories. 

Iris  Kameny:  Further  breakdown  DATA  STANDARDS  and  provide  definitions  for  it 
and  its  subcategories. 

Eleanor  Schro£d6r  * 

( 1 )  Provide  definitions  for  OCEANOGRAPHY  and  its  subcategories. 

(2)  Provide  definitions  for  NAVIGATION  and  its  subcategories.  (Coordinate  with 
Dave  Danko) 

Pat  Simes:  Provide  definitions  for  HUMAN  FACTORS  subcategory. 

Richard  Siquig: 

(1)  Provide  definitions  for  SPACE/UPPER  ATMOSPHERE  and  its  subcategories. 
(Coordinate  with  William  Jordan) 

(2)  Provide  definitions  for  WEATHER  and  its  subcategories. 
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B.  Data  Sources  Responsibilities 

ATT.  WORKING  GROUP  MEMBERS:  review  definitions  and  responsibilities  in 
Appendix  C.  Provide  comments  and/or  modifications  to  Chien  Huo  NLT  1 1  January 
1995. 

C.  JM&S  Data  Sources  Survey 

AT  T.  WORKING  GROUP  MEMBERS:  review  Dave  Danko's  Phase  II  survey 
questionnaire.  Send  comments  to  Chien  Huo  NLT  January  1 1, 1995.  This  action  item 
is  especially  directed  at  the  following  people:  JIM  AUGINS,  BILL  BOWERS, 
CATHY  CORLEY,  DAVE  DANKO,  RON  FARKAS,  JIM  HAMMOND,  IRIS 
KAMENY,  CHRIS  OLSON,  ELEANOR  SCHROEDER,  and  RICHARD  SIQUIG. 

D.  Other 

Chien  Huo:  Consolidate  responses  received  by  1 1  January  1995  and  prepare  package 
for  submission  to  DMSO  MSWG.  Forward  copies  of  final  package  to  working 
group  members. 
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14.6  SUMMARY  OF  BRIEFING  BY  MS.  MARY  POLYDYS  ON  DoD  SYSTEM 
INTERFACES  AND  DATA  EXCHANGES 

Ms.  Polydys  is  in  the  Staff  Directorate  for  Enterprise  Integration  at  DISA.  She  is  the  integration 
manager  for  cross-functional  integration. 


^^l^^IxrfJwiTMtkmPap^entitled^STATUS  UPDATE:  SYSTEM  INTERFACES  AND 

(2)  SKK==ER  GUIDE  did  10/24/94 

(3)  Ilement  information  COLLECTION  INSTRUCTIONS  dtd  10/19/94 

(4)  PICK  LISTS  for  Format  3-2  System/Application  Format  and  Interface/Exchange 
Format  dtd  1 1/10/94. 

The  Defense  Information  Systems  Agency  was  tasked  to  support  DASD(IM),  DoD  Principal 
Staff  Assistants,  J-6,  the  Services,  and  agencies  in  order  to  satisfy  the  requirements  as  dictated 
the  ASD(C3I)  memorandum,  System  Interfaces  and  Data  Exchanges,  dated  2  September  1994 
The  main  objective  was  to  capture  "source"  data  on  system  interfaces  and  data  exchanges  for  al 
legacy  systems,  interim  migration  systems,  and  target  or  objective  corporate  systems  tn  each 
functional  area  and  enter  selected  migration  system  data  element  information  into  the  Defense 
Data  Repository  System  (DDRS). 

The  primary  reason  behind  this  effort  was  that  although  a  system  proponent  could  possibly  not 
be  aware  of  all  the  other  systems  that  eventually  use  the  data  that  was  captured  or  created  by  the 
system,  every  system  proponent  should  know  the  source(s)  for  data  used  m  their  own  system.  It 
was  discovered  that  this  was  not  always  the  case. 

The  Defense  Integration  Support  Tools  (DIST)  was  utilized  to  capture  system/application 
information  and  initial  interface/exchange  information,  in  effect  to  be  the  repository  tor  this 
information.  A  phased  approach  was  used  to  collect  the  information  in  an  effort  to  ensure  data 

quality. 

Phase  I  of  this  project  entailed  registration/validation  of  systems  and/on applications.] Existing 
information  in  the  DIST  was  validated  by  the  appropriate  individuals.  Those  items  Aat  did  not 
exist  in  the  DIST  but  were  "sanctioned"  by  ASD(C3I)  and  DASD(IM)  as  a  designated  migration 
system  would  be  registered  by  personnel  identified  by  the  data  collection  coordinator  for  those 
systems  Phases  II  and  m,  which  began  on  10  December  94,  registers  the  interfaces  for  those 
systems  into  DIST  and  registers  the  data  elements  for  the  designated  migration  system  into 
DDRS  Analysis  of  the  data  occurs  in  Phase  IV  which  is  scheduled  to  begin  on  1  Jan  95.  In  t 
phase,  all  sources  will  be  identified.  Statistics  will  be  run  to  determine  how  many  interfaces  are 
reported  on  a  particular  system  and  this  information  will  be  provided  to  the  system  POC.  In 
way,  the  system  proponent  can  see  how  many  other  systems  are  using  their  system  s  data  and 
from  where  the  data  used  in  their  system  is  coming. 

In  the  long  run,  the  primary  beneficiary  of  the  information  will  be  the  principal  staff  assistants 
and  the  people  who  support  them  in  planning  the  evolution  of  the  migration  systems.  The  data 
collected  will  be  integrated  and  easily  available  for  use  to  the  functional  community  and 
components  and  those  in  support  of  their  activities. 
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14.7  APPENDICES 

A.  M&S  Taxonomy  Definitions 

1.  FINANCE:  TBD 

2.  ENVIRONMENT:  data  that  represents  the  characteristics  and  features  of  the 
terrain,  ocean,  natural  atmospheric  conditions  and  man-made  conditions. 

3.  EQUIPMENT:  equipment  is  a  discrete  element  (e.g.,  a  sensor,  weapon,  tank,  etc.) 
that  one  can  make  characteristics  &  performance  measurements  on. 

a.  EQUIPMENT  PERFORMANCE:  data  that  represents  how  well  equipment 
performs  its  mission  functions. 

b.  EQUIPMENT  CHARACTERISTICS:  data  that  represents  the  physical 
description  of  a  piece  of  equipment. 

4.  TACTICS,  TECHNIQUES  AND  PROCEDURES  COGNITIVE:  data  that 
represents  the  following. 

a.  TACTICS:  employment  of  units  in  combat;  the  ordered  arrangement  and 
maneuver  of  units  in  relation  to  each  other  or  to  the  enemy. 

b.  DOCTRINE:  fundamental  principles  by  which  military  forces  or  elements 
conduct  operations. 

c.  OPERATIONAL:  description  of  processes  for  carrying  out  mission 
functions. 

5.  FORCE  DESCRIPTION:  data  that  represents  the  organization  of  personnel  and 
equipment  that  comprises  force  composition,  unit  composition,  echelonment,  and 
command  relationships. 

6.  POLITICAL:  data  that  represents  the  influence  of  such  factors  as  economics  and 
demographics  on  the  politics,  especially  the  foreign  policy  of  a  state. 

7.  HUMAN  FACTORS:  data  that  represents  the  interaction  of  people  with 
equipment,  environment,  or  other  specified  conditions. 

8.  SERVICE  SUPPORT:  data  that  represents  the  assistance  provided  to  sustain 
combat  forces,  primarily  in  the  areas  of  administration  and  logistics. 

9.  SCENARIO:  data  that  represents  the  description  of  the  conditions  and  constraints 
for  evaluation  and  rationale  for  those  conditions. 

10.  TEST  RESULTS:  data  that  represents  the  examination,  experimentation,  or  trail 
under  specific  conditions  to  prove  the  value,  ascertain  the  nature,  or  ability  of  the 
thing  under  investigation  to  meet  requirements. 

1 1 .  UNIT  PERFORMANCE:  data  that  represents  the  force  effectiveness. 

12.  DATA  STANDARDS:  TBD 

13.  MISCELLANEOUS:  no  breakdown  at  this  time 

B.  M&S  Taxonomy  -  Updated 

NOTE:  *  denotes  change  made  at  this  meeting 
1.  FINANCE: 


<subcategories  to  be  determined> 
ENVIRONMENT: 
a.  Terrain 

1. 

Boundaries 

2. 

Elevation 

3. 

Hydrography 

4. 

Industry 

5. 

Physiography 

*6. 

Populated  Places 

7. 

Transportation 

8. 

Utilities 

9. 

Vegetation 
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*  1 0.  Soils/Surface  Materials 

b.  Oceanographic 

1.  Acoustics 

2.  Bathymetry 

3.  Biologies 

4.  Geology 

5.  Gravity 

6.  Geomagnetics 

7.  Sea  Surface 

8.  Water  Column  &  Currents 

c.  Weather,  Obscurants  &  Man-Made  Conditions 
*1.  Climatological 

*2.  Diurnal 

3.  Day/Night 

4.  Man-Made  Conditions  (e.g.  smoke) 

d.  Space/Upper  Atmosphere 
<subcategories  to  be  determined> 

*e.  EM/EO 

*  1 .  Natural  Emitter  Characteristics 

*2.  Manmade  Emitter  Characteristics 
*3.  Receptor  Characteristics 
*4.  Communications/Information  Transfer 
*5.  Propagation  Effects 
f.  Navigation 

1.  Obstructions 

2.  Landmarks 

3.  Non-electronic 

4.  Inertial 

5.  Radio 

6.  Satellite 

7.  Limits 

3.  EQUIPMENT: 

a.  Equipment  Characteristics 
*1.  Air 

*2.  Land 
*3.  Sea 
*4.  Space 
*5.  Missiles 

6.  Electronics 

7.  Sensors 

b.  Equipment  Performance 
*1.  Air 

*2.  Land 
*3.  Sea 
*4.  Space 

5.  Missiles 

6.  Electronics 

7.  Sensors 

4.  FORCE  DESCRIPTION:  . 

*a  Army  :  TO&E  (Table  of  Organization  and  Equipment) 

*b.  Marine  Corps:  TO/TE  (Table  of  Organization/Table  of  Equipment) 
*c.  Air  Force:  TA  (Table  of  Allowances) 

*d.  Navy:  SAIL  (Ship  Ammunition  Inventory  List) 

COSAL  (Coordinated  Supply  Allowance  List) 

WSF  (Weapons  System  File) 
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e. 

Intelligence:  foreign 

*f. 

Joint  Forces 

*g. 

Combined  Forces 

5. 

POLITICAL: 

a. 

Demographics 

b. 

Policy 

c. 

Economics 

6. 

HUMAN  FACTORS: 

a. 

Sensory 

b. 

Perception 

c. 

Physical 

d. 

Cognitive 

e. 

Social 

f. 

Emotional 

7. 

SERVICE  SUPPORT: 

a. 

Logistics 

b. 

Medical 

c. 

Personnel 

8. 

SCENARIO: 

*a.  Army 

*b.  Navy 

*c.  Air  Force 

*d.  Marine  Corps 

*e.  Joint/Combined 

*f.  Operations  Other  Than  War 

*g.  Pieces  (Planning  Guidance) 

9.  TEST  RESULTS: 

*a.  Operational  Testing 
*b.  Developmental  Testing 

10.  TACTICS,  TECHNIQUES,  AND  PROCEDURES  (TTP)  COGNITIVE: 

a.  Tactics 

b.  Operational 

c.  Doctrine 

1 1 .  UNIT  PERFORMANCE: 

*a.  Readiness 

*b.  Historical 
*12.  DATA  STANDARDS: 

<subcategories  TBD> 

13.  MISCELLANEOUS 

C.  Definitions  and  Responsibilities 
1.  DEFINITIONS: 

a.  AUTHORITATIVE  DATA  SOURCE:  an  organization  designated  and 
recognized  as  the  producer  of  best-estimate  values  for  one  or  more 
categories  of  data. 

b.  M&S  DATA  CENTER:  an  organization  with  a  database  recognized  by 
some  portion  of  the  M&S  community  as  having  gone  to  authoritative 
sources,  collected  the  best  data  possible  for  one  or  more  M&S  categories  of 
data  and  made  it  available  for  M&S  use. 
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2.  RESPONSIBILITIES:  .  r 

a  DATA  SOURCES:  a  data  source  has  the  responsibility  of  providing 
accurate,  complete,  and  current  data.  The  data  source  also  has  the 
responsibility  of  using  and  providing  data  to  others  as  required  and/or 
agreed  to  with  their  data  sources  or  regulations  and  of  safeguarding  the  data 
in  accordance  with  established  regulations.  Data  sources  should  be  able  to 
describe  in  detail  their  data  and/or  any  application  or  system, 
b.  DATA  CUSTOMERS:  customers  should  be  responsible  to  use  the  data  as 
agreed  to  in  accordance  with  any  formal  arrangements  such  as  MO  As  and  to 
properly  safeguard  the  data  as  required  by  regulations.  Customers  should 
report  to  the  data  providers  any  suspected  problems  with  the  data  or 
applications.  If  changes  are  made  to  any  data  handling  applications  they 
should  be  willing  to  share  those  changes.  Customers  should  be  willing  to 
share  in  the  cost  of  obtaining  the  data  if  required. 
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APPENDIX  F:  ACRONYMS 


A&T 

Acquisition  and  Technology 

ADSI 

Augins  Defense  Services,  Inc. 

ADSs 

Authoritative  Data  Sources 

ADTs 

Advanced  Technology  Demonstrations 

AIMSSS 

Army  Information  on  Models,  Simulations,  and  Studies  System 

AITS 

Advanced  Information  Technology  Services 

AJP  ACTD 

Advanced  Joint  Planning  Advanced  Concept  Technology  Demonstration 

ALSP 

Aggregate  Level  Simulation  Protocol 

AMD 

Allowance  Manpower  Document 

AMI 

ARMS  Model  Interface 

AMSAA 

Army  Material  Systems  Analysis  Activity 

AMSMO 

Army  Model  and  Simulation  Office 

ANDs 

Tagging  Format 

API 

Application  Program  Interface 

ARC 

ARC  Compression 

ARL/UT 

Applied  Research  Laboratories/University  of  Texas  at  Austin 

ARMS 

Automated  Resource  Management  System 

ARPA 

Advanced  Research  Project  Agency 

ASC 

ASCH  Text  File  (Unix) 

ASD 

Assistant  Secretary  of  Defense 

ATD 

Advanced  Technology  Demonstration 

ATO 

Air  Tasking  Order 

AVCAL 

Aviation  Allowance  List 

BFTT 

Battle  Force  Tactical  Trainer 

BMDO 

Ballistic  Missile  Defense  Organization 

BPR 

Business  Process  Re-engineering 

BUFR 

Binary  Universal  Format  for  the  Representation  of  Meteorological  Data 

C3 

Command  Control  Communications 

C3I 

Command  Control  Communications  and  Intelligence 

C4I 

Command  Control  Communications  Computers  and  Intelligence 

CATT 

Combined  Arms  Tactical  Trainer 

CCTT 

Close  Combat  Tactical  Trainer 

CDAd 

Component  Data  Administrator 
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CDIF 

CASE  Data  Interchange  Format 

CDIs 

Constrained  Data  Objects 

CECOM 

Communications-Electronics  Command 

CENTCOM 

U.S.  Central  Command 

CFDB 

Conventional  Forces  Database 

CFS 

Center  for  Standards 

CGI 

Common  Gateway  Interface 

CIM 

Center  for  Information  Management  or  Corporate  Information 
Management 

CINC 

Commander-in-Chief 

CISS 

Center  for  Information  System  Security 

CLI 

Call  Level  Interface 

CNO 

Center  for  Naval  Operations 

COLSA 

Corporation 

CONOPS 

Concept  of  Operations 

CORBA 

Common  Object  Request  Broker  Agent 

COSAL 

Coordinated  Supply  Allowance  List 

COSBAL 

Coordinated  Shore  Based  Allowance  List 

CSC 

Name  of  Company 

CSL 

Common  Security  Label 

CSSE 

Concurrent  Systems  Security  Engineering 

CSTO 

Information  Security  Program 

CTIS 

Combined  Terrain  Information  System 

DAd 

Data  Administrator 

DAPMO 

Data  Administration  Program  Management  Office 

DASP 

Data  Administration  Strategic  Plan 

DBA 

Database  Administrator 

DBF 

DBase  File  (Version  3  or  4) 

DBMS 

Database  Management  System 

DCE 

Distributed  Computer  Environment 

DDL 

Data  Definition  Language 

DDR 

Defense  Data  Repository 

DDR&E 

Director,  Defense  Research  and  Engineering 

DDRS 

Defense  Data  Repository  System 

DED 

Data  Element  Dictionaries 

DEEM 

Dynamic  Environmental  Effects  Model 

DEs 

Data  Elements 
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DGIWG 

Digital  Geographic  Information  Working  Group 

DGSA 

Defense  Goal  Security  Architecture 

DIA 

Defense  Intelligence  Agency 

DIS 

Distributed  Interactive  Simulation 

DISA 

Defense  Information  Systems  Agency 

DLG-E 

Digital  Line  Graph-Enhanced 

DLPCS 

Data  Link  Processing  and  Control  System 

DMAFF 

DMA  Feature  File 

DMDC 

Defense  Manpower  Data  Center 

DMS 

Defense  Message  System 

DMSO 

Defense  Modeling  and  Simulation  Office 

DOC 

MS-Word  (Windows) 

DoD 

Department  of  Defense 

DoDD 

Department  of  Defense  Directive 

DOIid 

Domain  of  Interpretation  Identifier 

DoN 

Department  of  Navy 

DRTWG 

Data  and  Repositories  Technology  Working  Group 

DSB 

Defense  Science  Board 

DSD 

Data  Sources  Directory 

DSI 

Defense  Simulation  Internet 

DSR 

Data  Standards  and  Repositories 

DSRS 

Defense  Software  Reuse  System 

DSU 

Data  Storage  Units 

DTR 

Data  Trouble  Reports 

E2DIS 

Environmental  Effects  in  Distributed  Interactive  Simulation 

EA 

Electronic  Attack  Environment 

EP 

Electronic  Warfare  Protection 

EPS 

Encapsulated  Post-Script  (Single  Graphic) 

ER1 

ER/WIN  Native  Format 

ERTWG 

Environmental  Representation  Technology  Working  Group 

ERX 

ER/WIN  ASCII  Export  Format 

ES 

Electronic  Warfare  Support 

ETMO 

Education,  Training  and  Military  Operations 

EXCIMS 

Executive  Council  on  Modeling  and  Simulation 

FACC 

Feature  and  Attribute  Coding  Catalog 

FDAd 

Functional  Data  Administrator 

FFRDCs 

Federally  Funded  Research  and  Development  Centers 
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FGDC 

Federal  Geographic  Data  Committee 

FIPS  173 

Federal  Information  Processing  Standard/Spatial  Data  Transfer  Standards 

FOIA 

Freedom  of  Information  Act 

GCCS 

Global  Command  and  Control  System 

GOTS 

Govemment-off-the-Shelf 

HLA 

High  Level  Architecture 

HQX 

MAC?? 

HTML 

Hyper  Text  Markup  Language 

HUMINT 

Human  Intelligence 

I/DBTWG 

Information/Database  Technical  Working  Group 

IDA 

Institute  for  Defense  Analysis 

IDBMS 

Integrated  Database  Management  System 

EDEF 

Integrated  Computer  Aided  Definition  Language 

IDEFO 

IDEF  Process  Modeling  Methodology 

IMINT 

Imagery  Intelligence 

iMSRR 

Interim  M&S  Resource  Repository 

IRC 

Internet  Relay  Chat 

IRDS 

Information  Resource  Dictionary  System 

IRM 

Information  Resource  Management 

IRR 

Information  Resources  Repository 

ISA 

Company  Name 

ISO 

International  Organization  for  Standardization 

itwg 

Information  Technology  Working  Group 

JDBE 

Joint  Database  Elements 

JIEO 

Joint  Interoperability  Engineering  Organization 

JM&S 

Joint  Modeling  and  Simulation 

JOPES 

Joint  Operations  Planning  and  Execution  System 

JSIMS 

Joint  Simulation 

JTF 

Joint  Task  Force 

JTF-ATD 

Joint  Task  Force-Advanced  Technology  Demonstration 

JWID 

Joint  Warrior  Interoperability  Demonstrations 

JWSOL 

Joint  Warfare  Simulation  Object  Library 

LEEGCCS 

Leading  Edge  Environment  for  Global  Command  and  Control 

M&S 

Modeling  and  Simulation 

MASINT 

Measurement  &  Signature  Intelligence 

MC&G 

Mapping,  Charting,  and  Geodesy 

MEL 

Master  Environmental  Library 

-201- 


MIIDS 

Military  Intelligence  Integrated  Data  System 

MISSI 

Multilevel  Information  System  Security  Initiative 

MOA 

Memorandum  of  Agreement 

MSIM 

Modeling  and  Simulation  Information  Management 

MSIRR 

Modeling  and  Simulation  Information  Resources  Repository 

MSIS 

Modeling  and  Simulation  Information  System 

MSMP 

Modeling  &  Simulation  Master  Plan 

MSRR 

Modeling  and  Simulation  Resource  Repository 

MSWG 

Modeling  and  Simulation  Working  Group 

NAAL 

NAVSEA  Ammunition  Allowance  List 

NASA 

National  Aeronautics  and  Space  Administration 

NATE 

North  American  and  US  Space  Command  Integrated  C2  Analyst  Test 

NAVOCEANO 

Naval  Oceanagraphic  Office 

NDRI 

National  Defense  Research  Institute 

NID 

A  Database  Used  by  Tecnet 

NIIIP 

National  Industrial  Information  Infrastructure  Protocols 

NISMC 

Naval  Information  Systems  Management  Center 

NIST 

National  Institute  of  Standards  and  Technology 

NRaD 

Navy  Research  and  Development 

NRL 

Naval  Research  Laboratory 

NWTDB 

Navy  Warfare  Tactical  Database 

OASIS 

Operational  Analysis  and  Simulation  Interface  System 

ODBC 

Object  Database  Consortium 

ODBCS 

Open  Database  Connectivity  Standard 

ODMG 

Object  Data  Management  Group 

OMG 

Object  Management  Group 

OPSEC 

Operational  Security 

OSD 

Office  of  the  Secretary  of  Defense 

PCAT 

Personal  Computer  Access  Tool 

PCTE 

Portable  Common  Tools  Environment 

PDU 

Protocol  Data  Unit 

PIRR 

Prototype  Information  Resources  Repository 

PMI 

Production  Modernization  Initiative 

POA 

Naval  Air  Program  Operating  Allowance 

PS 

Post-Script  Document 

RCL 

Rule  Constraint  Language 

RDBM 

Relational  Database  Management 

-202- 


RDBMS 

Relational  Database  Management  System 

RFP 

Request  for  Proposal 

RLF 

Reuse  Library  Framework 

RTF 

Rich  Text  Format  (ASCII  Exchange  Format) 

SAFORS 

Semi  Automated  Forces 

SAI 

Subject  Area  Information 

SDE 

Standard  Data  Element 

SEMP 

System  Engineering  Management  Plan 

SGML 

Standard  Generalized  Markup  Language 

SIGINT 

Signals  Intelligence 

SIMDATAM 

Simulation  Data  Management  Simulation 

SMIB 

Security  Management  Information  Base 

SML 

Structured  Modeling  Language 

SOCOM 

Special  Operations  Command 

SPAWAR 

A  Navy  Program 

STOW 

Synthetic  Theater  of  War 

SWAR 

Solid  Waste  Automated  Repository 

SWG 

Standards  Working  Group 

TA 

Table  of  Allowances 

TADILS 

Tactical  Data  Information  Link 

TAFIM 

Technical  Architecture  Framework  for  Information  Management 

TBD 

To  be  Decided 

TCB 

Trusted  Computing  Base 

TCSEC 

Trusted  Computer  Security  Evaluation  Criteria 

TIGER 

Topologically  Integrated  Geographic  Encoding  and  Referencing 

TU 

Training  Command 

TO&E’s 

Table  of  Organization  and  Equipment 

TO/TE 

Table  of  Organization/Table  of  Equipment 

TRAC 

Training  Command 

TRADOC 

Training  and  Doctrine  Command 

TRM 

Technical  Reference  Model 

TTP 

Tactics,  Techniques,  and  Procedures 

TWGs 

Technical  Working  Groups 

TWISTIAC 

Name  of  an  Information  Analysis  Center  that  Supports  Modeling  and 

TXT 

ASCH  Text  File  (MS-DOS) 

UDI 

Unconstrained  Data  Items 

URL 

Universal  Resource  Locator 
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USACOM 

USMTF 

UTSS 

VV&A  TWG 

VV&A 

VV&C 

WAROOM 

WAIS 

WGs 

WP5 

WSF 

WWMCCS 

WWW 

Z 

ZIP 


US  Atlantic  Command 

United  States  Message  Text  Format 

Universal  Threat  System  for  Simulators 

Verification,  Validation  and  Accreditation  Technical  Working  Group 

Verification,  Validation  and  Accreditation 

Verification,  Validation  and  Certification 

VV&A  Repository  Online  of  Models  and  Simulations 

Wide  Area  Information  Server 

Working  Groups 

Word  Perfect  5.x  Document 

Weapons  System  File 

World  Wide  Military  Command  and  Control  System 

World  Wide  Web 

Unix  Compression 

ZIP  Compression  Format 


